A curated collection of articles exploring this topic in depth.
Retrospective: The Cost of Intent
A pragmatic look at what worked, what was overkill, and what I would do differently if I were starting again.
The goal of this series was to document the design of a personal blog as a production-grade system as well as some of the features I've built in. Now that the system is stable and the architectural pillars are in place, it is time for an honest assessment of the results.
Software Engineering is the management of trade-offs. While the choices made here were intentional, they were not without cost.
What worked: The non-negotiables
If I were starting this project again today, three decisions would remain exactly the same.
1. Static export architecture
The decision to treat the site as a collection of immutable files has contributed more to its reliability than any other choice. I never worry about server uptime, database connections, or runtime vulnerabilities. The delivery layer (CloudFront) handles the heavy lifting, leaving the origin (S3) entirely private.
2. Identity federation via OIDC
Eliminating long-lived AWS secrets from the deployment pipeline was a significant win for both security and simplicity. OIDC provides a clean, cryptographic trust relationship that requires zero maintenance. It is a "set and forget" security boundary that provides peace of mind.
3. Terraform as documentation
Managing the infrastructure through declarative code has paid for itself every time I needed to verify a configuration (especially during initial deployment and cut-over from the previous iteration of this blog's infrastructure). Instead of hunting through the AWS Console, I can read the source code. The reproducibility it provides ensures that the system is not a fragile collection of manual tweaks, but a defined environment.
What felt like overkill
While these choices were technically sound, their proportionality to a "simple blog" is a valid question.
The AWS overhead
Using AWS directly (S3, CloudFront, Route 53) provides a high degree of control, but it also introduces significant configuration overhead compared to managed platforms like Vercel, Netlify, or Wix. For a small site, the time spent configuring ACM certificates and OAC policies is objectively much higher than the "zero-config" alternatives.
CloudFront Functions
Using functions at the edge for URL rewrites and redirects is architecturally correct for this stack, but it adds another layer of code that must be versioned, deployed, and tested. In a simpler setup, these concerns are often handled by the hosting provider's proprietary configuration.
What I would change
Looking back, there are areas where I would refine the approach to reduce friction.
Faster local feedback loops
The content validation and build verification scripts, as discussed in previous posts, are essential for integrity, but I will be interested to see how they evolve and scale. I might need to invest more time in making these checks incremental, ensuring that the authoring experience remains fluid even as the "digital garden" grows.
Proactive link checking
While the system validates metadata and build artifacts, it does not currently check for broken outbound links. In a long-lived project, external links are the first thing to decay. I don't have a lot of outbound content, but as the site grows, adding an automated, periodic link checker could be a logical next step for maintaining the site's quality.
The real win: Intentionality
For me, building a production-grade blog was not about following a specific list of tools; rather, it was more about the discipline of making explicit decisions.
The value of this exercise was not the final site itself, but the process of building it. It forced me to confront architectural decisions, to design explicit security boundaries, and to treat content with the same rigour as code.
A personal project is the best environment for slow engineering. It allowed for the exploration of trade-offs without the pressure of a commercial deadline. By choosing to build "on purpose", I have created a system that is not only a home for my writing but a reflection of how I want to approach engineering work.