The Case for Boring Web Architecture

Executive Summary

Boring web architecture is a deliberately small stack: pre-built static pages, a few short server functions at the edge, one relational database, object storage for files, and deployment by pushing to git. It is the least fashionable way to build a business website and, for most of them, the strongest.

Web development has spent a decade adding layers: frameworks on frameworks, build pipelines, orchestration, dashboards to watch the dashboards. Each layer solved a real problem for someone, and together they produced a situation where a five-page business site can depend on forty services and no single person who understands them all.

Here is the opposite argument. For the large majority of business websites and a surprising share of products, the boring stack wins. The advantage isn’t nostalgia. It is ownership, speed, and the ability for one person to hold the entire system in their head.

Boring architecture is a decision to spend your complexity budget on the product instead of the plumbing.

How do web stacks get heavy?

Complexity rarely arrives as a single bad decision. It accumulates through reasonable ones. A site needs a form, so it adds a form service. The form needs spam protection, so it adds another. Content needs editing, so it adds a headless CMS with its own login. Pages need to feel fast, so they add a rendering strategy with caching rules nobody documents.

Each addition is defensible. Together they create three problems that rarely appear in the original business case.

The first is operational: every service is something to monitor, pay for, secure, and migrate when the vendor changes terms. The second is cognitive: the system can only be changed safely by someone who knows how all the parts interact, and that someone gets harder to hire, or becomes you. The third is strategic: your product’s behavior is now shaped by the roadmaps of a dozen companies, none of which are accountable to you.

What does a boring web architecture look like?

The alternative has four parts, and none of them are exciting.

Pages are built ahead of time. Most of a business site never changes between requests. Pre-building it into plain HTML means the page is ready before the visitor asks, there is nothing to crash under load, and the whole site can be served from a content network that handles traffic spikes as a matter of routine.

Dynamic behavior lives in small functions. A form submission, a payment webhook, an AI call: each is a short function that runs when needed and does one thing. Functions at the edge start quickly, cost close to nothing at low volume, and can be read in a single sitting.

State lives in one boring database. A relational database with a few well-named tables handles more business logic than most teams expect, and everyone can reason about it. Files that don’t belong in the database go in object storage.

Deployment is a git push. The repository is the source of truth, the platform builds it, and rolling back is reverting a commit. There is no pipeline to babysit and no release ritual to remember.

   git push
      |
      v
  +-----------+     build      +-------------------------+
  | repository| -------------> | static pages (HTML/CSS) |
  +-----------+                +-------------------------+
                                         |
                                         v
                               content network (edge)
                                    |          |
                    page request ---+          +--- form / webhook / AI call
                         |                                   |
                         v                                   v
                  served as a file                   small function
                  (nothing to crash)                  |           |
                                                      v           v
                                                relational DB   object storage

The site you are reading follows this pattern. It is Astro static pages on Cloudflare Pages, a few Functions handle submissions and the optional AI interview, a D1 database holds project requests, and R2 storage holds attachments. A full build of well over a hundred pages takes about ten seconds, and the number of moving parts is small enough to document in a single short runbook.

Boring or layered: which stack fits the job?

The point is not that every product should be static. It is to match the architecture to the actual need, and to pay for complexity only where a need demands it.

If your product is…	Boring stack (static + functions + one DB)	Layered stack (SSR, CMS, orchestration)
A brochure or service site	Fits well; nothing to add	Overbuilt
A content site with one or two editors	Fits well; markdown or a file-based editor	Only if editors need roles and workflows
A site with forms, payments or webhooks	Fits well; one function per job	Usually unnecessary
A site with an optional AI feature	Fits well; one capped function with a fallback	Unnecessary unless the AI is the product
A logged-in app with per-user pages	Possible, with care	Often the right choice
A real-time collaborative product	Poor fit	Right choice
A multi-team publication with approval workflows	Add an editing tool that outputs plain files	Reasonable, if exit stays cheap

Read the table top to bottom as a gradient. The further down you go, the more a layered stack earns its keep, and the more important it is to ask what each layer is for.

Why is boring architecture an ownership argument?

Boring stacks aren’t just cheaper. They keep control in your hands.

When pages are files, you can move them to another host in an afternoon. When functions are short, you can rewrite one without understanding the others. When the database is relational and the schema is in the repository, your data is portable by default, and the migration history is a readable record of every decision you made about it.

Compare that to a stack where content lives in a vendor’s cloud, logic lives in a visual workflow tool, and the site is assembled at request time from five APIs. That stack may be faster to start. It is also a stack where your business continuity depends on terms you didn’t negotiate, and where the answer to “what happens if this vendor disappears” is a long, uncomfortable silence.

This is the same distinction as in our earlier argument about system builders and participants. Participants rent their leverage, and builders own theirs. The web stack is one of the most concrete places that choice shows up.

A worked example (illustrative)

Consider a hypothetical three-person home-renovation company that wants a service site, a quote request form, a gallery of finished jobs, and a way for customers to attach photos. This is an invented example to show the reasoning.

A layered build might add a headless CMS for the gallery, a form service for quotes, a file-upload service for photos, an automation tool to connect the form to email, and a server-rendered framework to tie them together. That is five vendors and five logins for a business whose site changes a few times a year.

A boring build treats each need as a small question:

Pages and gallery. Service pages and gallery entries are files in the repository, built into static HTML. Adding a finished job is adding a folder.
Quote request. One function validates the form, checks for bots, writes a row to the database and sends an email.
Photo attachments. The same function stores uploads in object storage and records the reference in the row.
Deploy. Push to git. If something breaks, revert.

What breaks if a vendor changes terms? In the boring build, almost nothing outside the host, because the pages are files and the data is a standard database. What does the owner need to understand? Where the repository is and where the database is. The example is simple on purpose. That’s the point.

What are the limits of boring architecture?

Boring architecture has limits, and pretending otherwise would be its own kind of fashion.

Highly personalized, real-time products need server rendering, caching strategy, and often more sophisticated state management. A collaborative editor is not a brochure site, and shouldn’t be built like one. The test is whether the complexity is serving a user need or a developer preference.

Content-heavy teams may need an editing interface with roles and workflows. A repository of markdown files is wonderful for one person and unfriendly to twenty. The answer isn’t to avoid editing tools, but to pick one that outputs plain files you own, so leaving it later is cheap.

Scale comes in two kinds. Static delivery handles traffic scale remarkably well. Organizational scale, meaning many teams changing many things at once, is where conventions and tooling start to earn their keep. Adopt them when the pain is real, not when the blog post said so.

A rule of thumb

Before adding any component to a system, ask three questions.

What breaks, specifically, if I don’t add this?
Who is on call for it at two in the morning, and is the answer me?
How would I remove it in a year, and what would that cost?

If the answers are vague, the component isn’t ready to join the stack. The discipline isn’t to refuse complexity. It is to make every piece of it earn its place, in writing, before it becomes someone’s problem.

We turn those questions into a named routine, the Earn-Its-Place review, run whenever someone proposes a new service:

Name the failure. State the specific problem the component solves, in one sentence, without the vendor’s marketing words.
Name the owner. Write down who is responsible for it when it breaks.
Price the exit. Describe how you would remove it and what you would have to rebuild.
Try the boring version. Ask whether a static page, a short function or a database table would do the same job.
Record the decision. Put the answer in the repository, so the next person sees why the component exists.

Most proposals die at step four, which is the intended result.

Conclusion

The industry rewards novelty, and novelty is rarely the right choice for the person paying the bill. A stack you understand completely, can move in a day, and can run without a team isn’t a compromise. For most businesses it’s the strongest position you can have. All of your attention goes to what visitors see and what customers need, and none of it goes to keeping up appearances for your infrastructure.

Frequently asked questions

What is boring web architecture?

Boring web architecture is a deliberately small stack: pages built ahead of time as static HTML, a few short server functions at the edge for dynamic work, one relational database for state, object storage for files, and deployment by pushing to git. Its goal is a system one person can understand completely, move in a day and run without a team.

Is a static site good enough for a business website?

For most business sites, yes. Most pages never change between requests, so building them ahead of time makes them fast and resilient under traffic spikes. Anything dynamic, such as a form, a webhook or an AI call, runs in a small function. Static suits brochure, service and content sites far better than most owners expect.

When is a static architecture the wrong choice?

When the product is highly personalized or real time, such as a collaborative editor, it needs server rendering and richer state management. Large content teams may also need an editing interface with roles. The test is whether complexity serves a user need or a developer preference, and whether you can still export plain files.

How fast can a static site build and deploy?

Fast enough to stop thinking about it. Our own Astro site of well over a hundred pages builds in about ten seconds, and deployment is a push to git, with rollback done by reverting a commit. A short build loop means changes ship the same afternoon they are noticed, which is a real advantage.

Why does a simple stack matter for owning your website?

Because ownership follows portability. Static pages are files that can move to another host in an afternoon, short functions can be rewritten one at a time, and a relational schema kept in the repository makes data portable by default. Fewer rented parts means fewer things someone else can change underneath you.

How do you decide whether to add a new service to a web stack?

Ask three questions in writing. What breaks, specifically, if we do not add it? Who is on call for it at two in the morning, and is the answer us? How would we remove it in a year, and what would that cost? If the answers are vague, the component is not ready to join the stack.