The case for boring architecture

Every few years the industry rediscovers that most products are best served by a monolith, a relational database, and a queue. Then a new architecture trend arrives, and teams spend their runway on infrastructure their traffic will never justify.

Boring architecture is a competitive advantage for early products. It means one deploy target, one place to look when something breaks, and a new engineer onboarding in days instead of weeks. Complexity should be purchased when a measurement demands it — not pre-ordered because a conference talk was persuasive.

We default to boring. Clients sometimes push back, right up until they see how fast boring ships.

What does boring architecture actually look like?

For most early products, a stack like this covers years of growth:

• One application, such as a Next.js or Django app, deployed as a single unit.
• One relational database, usually PostgreSQL.
• A background job queue for email, imports and anything slow.
• Managed services for login, file storage, email and payments.
• One hosting target with automatic deploys from the main branch.
• Error monitoring and logs from day one.

Every part is widely understood, well documented and easy to hire for.

Why not microservices from the start?

Microservices solve real problems: separate teams deploying independently, parts of a system with very different scaling needs. Most early products have neither. What they get instead is:

• Several deployments to coordinate for one feature.
• Network calls and failure modes where a function call used to be.
• Data spread across services, which makes simple reports hard.
• More infrastructure to pay for and monitor.

None of that helps you learn whether users want the product.

When is it time to add complexity?

Add it when a measurement asks for it, not before:

• A specific part of the system is slow and profiling shows it cannot be fixed in place.
• One workload needs to scale very differently from the rest, such as heavy video processing.
• Several teams are blocking each other on the same deploy.
• A compliance requirement demands isolation of certain data.

Even then, the usual first step is to split out one piece, not to redesign everything.

How does this help the business?

Simple systems are cheaper to run, faster to change and easier to hand over. A new engineer can understand the whole thing quickly, and a client is never locked into the studio that built it. That matters as much to a small business as to a startup. We look at the running-cost side in the AWS bill is an architecture diagram and at a common early decision in ECS or Lambda for a product that is still changing.

This is the default behind every custom web app and SaaS MVP we build.