§ CAPABILITY

Web Application Development

Web applications that stay fast and usable as they grow. Rendering strategy chosen against what the page actually needs, and accessibility treated as a requirement rather than a later audit.

Who
Delivered by a senior team assembled for the engagement, against a defined scope.
Request a call How the work runs

What you're seeing

The application is slow on one route and nobody can say which change made it slow.
Usually means There is no performance budget in CI, so regressions arrive one dependency at a time and none of them is individually large enough to notice.
A design change means editing the same thing in nine files.
Usually means There are components but no component contract — props and states were never defined, so each usage diverged. This is the cost that makes teams want a rewrite.
An accessibility audit arrived from a customer's procurement and the findings are structural.
Usually means Semantics and focus management were left until after the build. Retrofitting them costs several times what building them in would have, because the fixes are in the component structure rather than in attributes.

Rendering is a per-route decision

A marketing page, a dashboard and a settings form have different needs, and applying one strategy to all three is how applications end up slow in the places that matter commercially and over-engineered in the places nobody would have noticed.

The marketing page should be static and served from an edge, because its content changes weekly and its job is to be fast for someone who has never been here before. The dashboard should render on the server for the shell and hydrate for the interaction, because it is behind authentication and its data is per-user. The settings form can be entirely client-rendered, because nobody arrives at it cold and its first paint is not a commercial event.

None of that is exotic. What is unusual is writing the decision down per route, so the next person can tell whether a page is server-rendered on purpose or because it was copied from the one next to it.

The states nobody draws

Empty, loading, error, partial permission, and the row with a name three times longer than the mock.

Most of the visible quality difference between two applications built by competent teams is in those states. Designers rarely draw them, because they are not what a design review is for. Engineers rarely raise them, because raising them means asking for more design work. So they get invented during implementation, one at a time, by whoever is on the ticket — which is why the empty states in a mature application contradict each other.

The fix is unremarkable: name them during component work, decide them once, and put them in the component contract alongside the props.

The budget defends itself

A performance budget in CI will occasionally block a pull request over something that feels trivial, and someone will argue that this specific dependency is fine.

They are usually right about the specific dependency and wrong about the pattern. Applications do not become slow in one commit — they accumulate, and every individual addition is defensible. The gate is not a judgement about any one change; it is the only mechanism that sees the sum.

Where it sits

This is a capability inside Software Development and it is rarely bought alone — the interface is a view onto something, and that something is usually built in the same engagement as Backend & API.

The other close neighbour is QA & Test Strategy: browser-level tests are where accessibility and interaction regressions are actually caught, and deciding what belongs there rather than in a unit test is a decision worth making once, early.

How the work runs

  1. Choose rendering per route

    Static, server-rendered or client-rendered decided by what each page needs, rather than one strategy applied to a whole application because the framework defaulted to it.

  2. Establish a component contract

    Shared components with defined props and states, so a design change is one edit and not a search across the codebase.

  3. Hold a performance budget

    Core Web Vitals measured in CI against a budget, because performance regressions arrive one small dependency at a time.

  4. Build accessibility in

    Semantics, focus management and keyboard paths as part of the component work. Retrofitting WCAG after launch costs several times what building it in does.

What arrives

  • An application with a documented rendering strategy per route
  • A component library with props, states and usage documented
  • Core Web Vitals budgets enforced in CI
  • Keyboard and screen-reader paths covered by automated tests

What it costs your team

Design review sessions and around three hours a week from whoever owns the product surface.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • Rendering is chosen per route, not per application

    Costs It is more to hold in your head than one strategy applied everywhere, and it requires a written record of why each route is what it is.

    A marketing page, a dashboard and a settings form have genuinely different needs. One strategy applied to all three produces an application that is slow where speed is commercial and over-engineered where nobody would have noticed. The framework's default is a default, not a decision.

  • A performance budget runs in CI

    Costs It will block a pull request for a regression somebody considers unimportant, and that argument happens regularly.

    Sites do not become slow in one commit. They accumulate — a font here, an analytics tag there, a dependency that pulled in a date library — and no individual step is worth objecting to. An automated gate is the only thing that catches accumulation, because a human reviewing one change will always let it through.

  • Accessibility is built during component work, never audited afterwards

    Costs It slows the component phase and requires designers to answer questions about states they had not considered.

    The expensive accessibility failures are structural: a modal that does not trap focus, a table built from divs, a form whose errors are only conveyed by colour. Fixed during the build these are free. Found by an audit, they are a rebuild of the component and everything using it.

Frequently Asked Questions

Building the browser-side product — the interface, the state it holds, how it talks to the server, and how it behaves on slow networks and in accessibility tooling. The distinction from a website is that the value is in the interaction rather than in the content, which changes almost every technical decision behind it.
React with Next.js for applications, Astro where most of the page is content and interactivity is local to a few components. The choice follows what the product is. Where you already have a stack that works, we say so rather than proposing a migration that buys nothing a user can see.
Yes, and the useful version of that means being in the file early enough to raise the states designers rarely draw: empty, loading, error, partial permission, and the row with a name three times longer than the mock. Most of the visible quality of an application lives in those.
Built in during component work rather than audited afterwards. The requirements applied during a build are mostly free — semantic elements, focus order, labels, contrast. The same requirements applied to a finished application are structural fixes to components other components depend on.
A budget checked in CI, on the metrics a user experiences rather than on bundle size alone. Performance is not a launch state, it is a property that degrades unless something is defending it, and a human reviewer defending it one pull request at a time will lose.

Sources

Page reviewed