02 Web applications
Web apps that behave like products, not pages.
Dashboards, portals, configurators, and data-heavy interfaces with real state, authentication, and APIs underneath. We build them as software, with performance budgets and accessibility designed in, then prove it with work you can inspect.
02 The position
The line between 'website' and 'web app' is where most teams get hurt.
A brochure site can survive being thrown together. A web application cannot. The moment you add real state, user accounts, data that has to stay consistent, and interactions that have to feel instant, the cost of building it like a website comes due, in bugs, in slowness, in a codebase nobody wants to touch.
We build web applications as software from day one. That means a real architecture for state and data, an API layer designed rather than improvised, and a performance budget that is enforced in the build, not hoped for. It also means accessibility is part of the engineering, not a compliance task bolted on at the end.
The result is an interface that stays fast and predictable as it grows, the same standard we hold for every software build and every AI feature we ship.
03 Philosophy
Fast is a feature. We treat it like one.
Speed is not a nice-to-have you tune at the end. In a web application, latency is friction, and friction is lost users, lost conversions, and lost trust. So we set a performance budget before we write a line of interface code, and we hold the build to it.
That discipline is visible in our work. The Roseville product suite, a calculator, estimator, and order builder doing real work in the browser, ships at 94/97/100/100 Lighthouse while doing far more than a typical marketing site. That is not an accident of a fast template; it is the outcome of engineering for performance on purpose.
In a web app, every 100 milliseconds is a decision the user makes about whether to trust you.
04 Capabilities
What we build into every web app.
- 01
Real state & data architecture
Client and server state designed deliberately, so the interface stays consistent and predictable instead of drifting into a tangle of edge cases.
- 02
Auth, roles & multi-tenancy
Authentication and authorization done correctly, the part that is invisible when it works and catastrophic when it does not.
- 03
Designed APIs
Typed, versioned, documented API layers, the contract between your interface and your data. Software-grade API engineering, not improvised endpoints.
- 04
Performance budgets
Core Web Vitals and interaction latency treated as build-time constraints. See our INP optimization approach for how we keep interactions instant.
- 05
Accessibility, engineered in
Keyboard, screen-reader, and contrast correctness built during development, not retrofitted after a compliance scare.
- 06
Observability
Error tracking, logging, and the instrumentation that means you find problems before your users report them.
05 Method
How we think about the work.
- 01
Design the data, then the screen.
Most web-app pain is data-model pain wearing a UI costume. We get the shape of the data and the API right first; the interface gets dramatically simpler when the foundation is sound.
- 02
Budget performance up front.
We set a performance target before building and enforce it in CI. It is far cheaper to stay fast than to rescue a slow app after launch.
- 03
Accessible by construction.
We build with semantics, keyboard, and contrast correct from the first component, so accessibility is a property of the system rather than a remediation project.
07 Proof
The work that proves the method.
-
An interactive product suite, material calculator, project estimator, and order builder, doing real work in the browser while staying near-perfect on Core Web Vitals.
Read the case → -
A credential-gated, scarcity-driven interface where the application behaviour is the product, not a brochure with a form bolted on.
Read the case →
08 Related thinking
Where this work goes deeper.
· Questions we get
Common questions, honest answers.
-
What's the difference between a website and a web application to you?
A website presents content; a web application does work, real state, accounts, data consistency, and interactions that have to feel instant. We engineer the second category as software, because building it like a website is exactly where teams get hurt.
-
Do you use React for everything?
No. We reach for interactivity where it earns its place and keep the rest static and fast. Astro lets us ship mostly-static pages with islands of rich interactivity, which is often the right architecture for a performant web app. We choose per surface, not per dogma.
-
How do you keep web apps fast as they grow?
Performance budgets enforced in the build, careful state and data architecture, and instrumentation so regressions are caught early. Staying fast is a discipline maintained over time, not a one-time tuning pass.
-
Can you take over an existing web app?
Yes. We regularly inherit applications that have become slow or fragile, stabilise them, and then move them forward. We will give you an honest assessment of whether to refactor or rebuild before either of us commits.
· Working together
Have a web app that needs to behave like a product?
Whether it is a new build or an existing app that has started to creak, the first step is the same, a real conversation about the architecture and whether we are the right team to own it.
Start a conversation