Building in public / platform engineering
How I built this website
A small website became a practical exercise in turning personal knowledge into a tested, secure and automated public service.
I wanted aboutcorin.com to do more than present a conventional CV. It needed to explain how I work and give people useful ideas to take away.
CI/CD, DevSecOps, platform engineering, secure by design, cost-efficient and scalable: all for this little website.
This is the story of how I built it, from the Obsidian vault that holds my working knowledge through to Codex, OpenTofu, GitHub Actions and the controls around the deployed service.
Start with the content
I started with the content, not the framework. My Obsidian vault contains years of notes, principles, project records and unfinished ideas. It also contains material that should never become public. The first job was to identify the ideas that could stand alone for a reader.
The vault became the source of context, examples and publishing ideas. It became a representation of me. Having that source allowed me to build this website quickly without losing the core goal of answering a simple question: who is Corin?
The hard part was not writing HTML. It was turning intent into decisions that could be checked: what the site is for, what belongs in public, how the existing infrastructure works, which changes need review and how to verify a release.
AI helped with the work, not the responsibility
I have used Claude and ChatGPT with Obsidian to help build and organise my vault - my external brain. For the website I used Codex to inspect material, compare options, draft copy, write code and prepare checks.
Why Codex? I already had a personal OpenAI account and it was the tool available to me. Could I have done this with Claude? Absolutely. The important point is not the brand. It is how the tool is used.
The work was not automatic. I supplied the goals, context and constraints. I decided which claims were true, which examples were suitable and what should be released. I followed every step. Human in the loop. As it should be.
The review questions were simple: Is it true? Is it mine to publish? Does it help the reader? Does it belong on this site?
Did AI get it right first time? No, and I did not expect it to. But it enabled me to go from zero to a working website much faster.
Build a real product
I treated the site as a real product. Pages needed a clear purpose and coherent journey. Content, links, headings, metadata, contact details and error behaviour all mattered on desktop and mobile.
I wanted to apply as many of the principles and practices that I hold as I could in this project. The site is deliberately simple: static HTML, a shared stylesheet and limited JavaScript. A static site still has routes to preserve, assets to deploy, caches to invalidate and releases to control.
It was also a small platform to operate: a service boundary, release process, infrastructure, identity, observability and failure modes. That is a compact version of the work I do at larger scale.
Adopt what already existed
The website was already hosted in AWS. I inspected the live resources and the routes that had to survive the change, then imported the infrastructure rather than recreating it.
I started with Terraform, then made a deliberate decision to pivot to OpenTofu. It represented the real estate and supported the review, state and automation discipline I wanted.
The first useful result was a no-change plan. The declared configuration matched the deployed resources. That gave me a safer foundation for later changes.
The implementation stays small enough to understand end to end. That is the point of proportionality: choose the controls and automation the service needs, then make them useful to the people who run it.
Identity and delivery are part of the design
GitHub Actions uses OpenID Connect to request short-lived AWS credentials. AWS checks the repository and release context before granting access. No long-lived AWS access keys are stored in the repository.
The roles are separate. The site role can write reviewed files and request a cache invalidation. The infrastructure role is broader because it runs OpenTofu, but uses a separate plan and apply process. A content deployment cannot change identity, DNS or the infrastructure protecting the site.
Pull requests and protected main provide review. Automated checks validate the site structure, links, metadata and assets. OpenTofu formatting, validation and plans cover infrastructure changes. Infrastructure apply is a separate action.
Each part has a clear responsibility: GitHub handles review and workflows; OIDC provides temporary identity; AWS roles provide bounded authority; S3 stores the site; CloudFront delivers it; checks provide evidence.
How the system fits together
The diagram is deliberately simple. It shows the two paths that matter: the path from knowledge to a reviewed release, and the path from that release to a running public service.
The delivery sequence
- ContextCapture the idea, constraints and intended outcome in the vault.
- ChangeUse Codex to explore, draft and implement a small, inspectable change.
- CheckRun local content, link, formatting, validation and plan checks.
- ReviewOpen a pull request and review both the change and the proposed infrastructure effect.
- ReleaseMerge to protected
main, then run the appropriate controlled workflow. - VerifyCheck the live routes, deployed files, permissions and operational output.
Guardrails that enable speed
The controls are there to make safe change easier to repeat, not to create ceremony for its own sake.
main keep release decisions visible.Verify after publication
I checked the deployed pages through their public HTTPS routes, verified the preserved paths and matched the deployed content to the approved release files.
The next operational layer is privacy-safe feedback from CloudFront logs. The output is aggregate information, not a public record of visitors. It has its own review of code, permissions and public output.
Collect what is needed, keep raw data private and publish only safe aggregates.
What I learned
The website became both a working service and a case study in how I work at larger scale. It contains a small version of the practices I use in platform engineering, DevOps and infrastructure as code: architecture, security, least-privilege identity, automated validation, controlled deployment, infrastructure state and operational verification.
Start with the purpose and the reader. Maintain the source of truth. Use AI to speed up thinking, while keeping responsibility clear. Inspect before changing. Use infrastructure as code when repeatability, review and recovery justify it. Build identity and permissions into the design. Test as a user would. Preserve what already works.
The scale is different, but the questions are the same: what is this for, who owns the decision, what could go wrong, how would we know and how easily could we change it?
That is how I built aboutcorin.com: as a small public service with a clear purpose, secure deployment architecture and controlled change.