Web Applications

Rendering strategy is a decision, not a default

Front ends where the rendering approach — static, server-rendered or client-side — is chosen against the content and the audience rather than habit.

Why this comes up

A great deal of the web is built as a single-page application because that is what the starter template did. For an internal dashboard behind a login, that is fine. For a public page whose job is to be found and read, it means the first thing a visitor receives is an empty div and a request for half a megabyte of JavaScript — on a phone, on a connection you should not assume much about.

The opposite mistake is just as common: static generation applied to content that changes hourly, producing a build pipeline that runs constantly and still serves stale pages. Both are the same error, which is picking the rendering strategy once, globally, before knowing what any particular route does.

We choose per route. A marketing page is static. A search page is server-rendered so results are in the HTML. A drag-and-drop editor is client-side, because there is no argument for anything else. Performance and accessibility then get treated the way correctness is — a budget agreed up front and checked in the pipeline, rather than an audit someone runs after launch and quietly files.

What you get

Deliverables, not adjectives

A rendering strategy chosen route by route

Static where content is stable, server-rendered where it must be indexed or personalised, client-side where interactivity genuinely demands it. Written down with the reasoning, so the next person does not have to re-derive it from the code.

A component library your team can extend

Type scale, spacing, colour tokens and the component set that follows from them, built so a new page reuses existing structure instead of inventing a layout. The measure is whether someone can add a section next quarter without a designer and without it looking bolted on.

Performance budgets enforced in CI

Agreed limits on bundle size and Core Web Vitals, checked on every pull request so a regression is a failing build rather than a discovery six months later. Images, fonts and third-party scripts included, since that is where the weight usually comes from.

Accessibility built in, not audited afterwards

Semantic markup, working keyboard paths, visible focus, sufficient contrast and screen-reader labelling — designed in, then tested. Retrofitting accessibility means rewriting components; building it in costs almost nothing.

Scope at a glance

Static, server-rendered or hybrid rendering per route
Performance budgets tracked against Core Web Vitals
Component libraries and design systems built for reuse
Semantic markup, keyboard paths and screen reader support

What we reach for

Defaults rather than rules. Each one gets argued against on a project where it does not fit — the reasoning matters more than the tool.

Framework: React with TypeScript, on Next.js or TanStack Start depending on the rendering profile.
Styling: Tailwind CSS with design tokens, so a re-theme is a variable change rather than a sweep.
Content: A headless CMS where non-developers must edit copy — which is more often than teams expect.
Testing: Playwright for the paths that matter, weighted towards flows rather than components.

How it runs

Durations are ranges because a single confident number this early is a guess in a suit.

Engagement shape

Usually fixed scope, since this is the work that can be specified most precisely.

Typical duration

Four to ten weeks for a marketing site; longer for an application front end.

Starts with

A route inventory — every page, its purpose, its audience and how often its content changes.

When this is the wrong thing to buy

We would rather lose the enquiry here than three months in. If you recognise your situation below, say so on the first call and we will tell you what we would do instead.

A five-page brochure site on a tight budget. A template on a hosted platform will serve you better, and we will say so.
Rebuilding a working front end because the framework is unfashionable. That is a cost with no user-visible benefit.
Design-only engagements. We build what we design; we are not a studio that hands over comps.

Questions we get asked

Can our marketing team edit the site without a developer?

If that is a requirement, say so at the start and we will build for it — a CMS, or content in structured files with a clear editing path. It shapes the architecture, so it is much cheaper as a stated requirement than as a later request.

How do you handle SEO?

Mostly by building the site properly: server-rendered HTML on public routes, one h1 per page, real URLs rather than hash fragments, per-page titles and descriptions, structured data, a correct sitemap, and page weight kept low. Beyond that, SEO is a content discipline rather than an engineering one, and we would rather be honest about the boundary than sell around it.

Do you work with an existing design?

Yes, and it usually goes well if the design covers real states — empty, loading, error, long text, small screens. If it does not, we will flag the gaps early rather than invent answers in code and surprise you at review.

What performance targets do you aim for?

We agree them with you before starting, because the right target for a content site differs from an authenticated application. For public pages the usual baseline is a Largest Contentful Paint under 2.5 seconds on a mid-range phone over a slow connection, with the budget enforced in the pipeline.

Talk to us about web applications

Send the problem rather than a feature list. You will get an approach, a range and an honest view of what it takes — including whether you need this at all.

Book a 15-min strategy call