Choosing Boring Architecture for the Right Reasons
When a static site, a CDN, and zero infrastructure are the most defensible engineering choice.
The decision
Every infrastructure engineer has the muscle memory to reach for load balancers, managed backends, Kubernetes, and CI/CD pipelines. The harder skill is knowing when not to use them.
For a project with no dynamic data, no authentication, and no real-time requirements, a static site served from a CDN is the most defensible choice. No servers to patch, no database to secure, no always-on compute cost, and a deployment model that fits in a single push.
What "boring" actually means
Boring architecture is not the absence of engineering judgment; it is the result of it. The goal is to match the complexity of the solution to the complexity of the problem, not the other way around.
The same principle applies inside platform teams. When an internal tool can be a static dashboard instead of a full-stack app, that's fewer dependencies to maintain, fewer on-call pages, and fewer security surfaces. The best platform engineers I've worked with consistently choose the simplest architecture that solves the actual problem.
When to evolve
The signal to add complexity is a real constraint, not an anticipated one:
- Dynamic user data that requires authentication and storage.
- Search or filtering that exceeds what client-side JavaScript can handle.
- Integration workflows that need server-side orchestration.
Until those constraints exist, adding infrastructure is cost without value. The architecture should evolve with the requirements, not ahead of them.
The broader lesson
This applies well beyond personal projects. In platform engineering, every service you add to the stack is a surface you maintain, monitor, and secure. Starting simple and adding complexity deliberately is a staff-level habit that pays dividends in operational cost, reliability, and team velocity.