It was fast with the demo data
A web application is not a website with a login. It is a piece of software that happens to run in a browser, and the things that break it — state, latency, data volume, offline, concurrent editors — are software problems, not design problems.
You might be here because
Situations we are brought in for
- The interface is fine in development and unusable against production data volumes.
- State is spread across a store, the URL, local storage and component memory, and they disagree.
- Two users edit the same record and the last one to save wins, silently.
- An accessibility audit came back and nobody knows how deep the remediation goes.
What you get
Concrete deliverables, not a retainer with a hope attached
Application architecture
Where state lives, what is server-rendered, what is cached and for how long. Decided deliberately and written down, rather than accreting one component at a time.
Interfaces that hold up at volume
Virtualized tables, paginated and streamed data, optimistic updates with real rollback. Tested against the data volumes you actually have, not a seeded fixture.
Real-time where it earns its place
Live updates, presence and collaborative editing built with an explicit conflict-resolution strategy — and left out where polling would have been fine.
Accessibility and performance budgets
WCAG 2.2 AA as a build requirement, keyboard paths tested, and Core Web Vitals enforced in CI so regressions fail a pull request rather than a quarterly audit.
How it works
Four phases, each with an exit you control
- 01
Profile
We establish the real constraints first: largest realistic dataset, slowest supported device, worst tolerable latency. Everything downstream is designed against those numbers.
- 02
Skeleton
One workflow built end to end — routing, data loading, error and empty states, keyboard access — as the pattern every subsequent screen follows.
- 03
Build
Feature work in cycles, with performance and accessibility checks running on every change rather than saved for a hardening phase that gets cut.
- 04
Prove
Load against production-scale data, assistive-technology testing, and the browser and device matrix your users actually run.
Tools we reach for
Chosen per problem, not per fashion
This is what we use most for web applications. If your team is already productive in something else, we work in that instead — familiarity in your team beats preference in ours.
- TypeScript
- SvelteKit
- React
- Node.js
- PostgreSQL
- Playwright
- WebSockets
Where this usually starts
Build Cycle
Most common
Build Cycle
Getting a defined product or feature set shipped to production
A dedicated senior team working in two-week cycles against an agreed outcome. You see working software at the end of every cycle and can change direction between them.
- Typical duration
- From 6 weeks
- Commitment
- Rolling, cycle by cycle
Includes
- A senior team sized to the work
- Two-week cycles with a working demo at the end of each
- Direct access to the engineers building it — no account layer
- Your repositories, your CI, your review process
- Production readiness and handover built into the plan
You keep
- Working software in production
- Test suite and CI pipeline
- Architecture and operations documentation
- Handover sessions with your team
Fee agreed after scoping. No commitment to that conversation.
Common questions
Which framework will you use?
Whichever fits the problem and your team. We reach for SvelteKit often because it produces less client-side JavaScript for the same result, and for React when the ecosystem or your hiring plan calls for it. If your engineers will maintain this after we leave, their familiarity outweighs our preference.
Do you work with our existing designers?
Yes, and we would rather. We work from your design system where one exists, and where it does not we build interface patterns as reusable components with the states — loading, empty, error, permission-denied — that mockups usually omit.
Can you fix an application rather than rebuild it?
Usually, and it is normally the better option. Most applications that look like they need a rebuild have three or four specific problems — an unbounded query, a state model that fights itself, a bundle nobody has looked at in two years — rather than a fundamental one. Finding out which is a short piece of work.
Other services
Product engineering
Ship the product your roadmap keeps promising — designed, built and maintained.
Platform & infrastructure
Make deploys boring, incidents rare, and cloud spend explainable.
Legacy modernisation
Untangle the system nobody fully understands — without stopping the business.
AI & applied ML
Put language models into production without betting the product on a demo.
Custom software
For the process no product on the market actually fits — built once, properly.
SaaS development
Multi-tenancy, billing and onboarding — the unglamorous parts that decide whether it scales.
API development
Interfaces other engineers have to live with — versioned, documented and hard to misuse.
Mobile apps
Apps that work on a bad connection, clear store review, and can be shipped weekly.
Next step
Think this is your problem?
Send us the shape of it. We will tell you whether it is a fit, what we would do first, and roughly what that takes.