Server-rendered first.

Every new web product we take on starts the same way. Before anyone picks a state library, before anyone draws a component tree, we write down what the page should be if no JavaScript ever runs. That document is short, and it is almost always closer to the final architecture than the one the team would have arrived at otherwise.

This is an unfashionable position to hold in 2026. It is also the one that has held up across every engagement we have shipped.

The default we pick.

The page is HTML. The server owns rendering, data access, and the cache. The client gets JavaScript only where interactivity genuinely changes the product — a form that needs live validation, a chart that needs to respond to a cursor, an editor. Everything else is a link, a form post, and a server response.

In practice, on the stack we default to, this looks like server components with small client islands. The boundary between them is a deliberate decision, not an accident of where someone reached for a hook.

Why we keep choosing it.

The first reason is debuggability. When the page is rendered on the server, a bug has one place to live. You read a request, you read a response, and the failure is in the code between them. When the page is assembled in the browser from a dozen client-side fetches, the same bug can hide in network timing, in stale cache, in a race between two effects. Senior engineers can chase that down. The cost is that they spend their week chasing it down instead of shipping.

The second reason is cost. A server-rendered page is cheap to host, cheap to cache at the edge, and cheap to keep fast as the product grows. A client-heavy page is cheap to start and expensive to keep. Three years in, the bundle is the product's biggest performance problem, and nobody on the team remembers why half of it is there.

The third reason is the one we say least and mean most. A server-rendered page is legible. The next engineer can open a route file, read it top to bottom, and understand what the page does. That is the property that makes software durable. Everything else is a consequence of it.

Where we deviate.

There are products where the page is the application — a canvas, a spreadsheet, a real-time editor, a complex internal tool with five panes of live state. For those, the client is the right place for the work, and we say so on day one. The test is honest: if you took the JavaScript away, would the page still be the product? If the answer is yes, server-rendered first. If the answer is no, build the client the product needs and treat the server as its backend.

Most products fail that test in the direction nobody expects. The marketing site, the dashboard, the settings screens, the admin tool, the checkout — they are documents with a few interactive moments. We build them that way.

What it costs.

Server-rendered first is not free. It asks the team to think about data on the server, about caching, about what a page actually needs before it is allowed to render. That is more work on day one than gluing a client app to a JSON endpoint. It is much less work on day three hundred, when the product is in production and the team is small.

We are comfortable paying the day-one cost because we are the team that has to read the code in year three. So is yours.