03Service
Web Applications
Measured against a mid-range phone on a mediocre connection — because that is what your customers have.
- Service
- 03 / 06
- Outcome
- Fast, accessible products people can actually use
- Core stack
- React · Next.js · TypeScript
Web performance is not a vanity metric. Every second of load time is a share of your visitors leaving, and most sites are tested on fast laptops on office broadband by the people who built them.
We build against explicit budgets on real hardware profiles: what renders on the server, what ships as JavaScript, how large the fonts and images are allowed to be. Those budgets are set during architecture and checked before each release, so performance is a requirement rather than a cleanup task.
Accessibility is handled the same way. Semantic structure, keyboard paths, visible focus and sufficient contrast are part of the component work, not an audit at the end — which is both the right thing to do and the cheapest time to do it.
Signs you need this
- The site is slow on a phone and nobody has been able to fix it
- Conversion drops between landing and the first real step
- Every new page is rebuilt from scratch with slightly different styling
- The product is unusable with a keyboard or a screen reader
- The marketing site and the product look like different companies
- Problem
- A slow, generic web product loses users before it gets a chance to be useful — and quietly costs conversion on every visit.
- Solution
- Web applications engineered for performance and clarity: server-rendered where it helps, measured against real device budgets, accessible by default.
- Outcome
- Pages load fast on a mid-range phone, the interface holds up under real use, and the product is usable by everyone you're selling to.
/What the work includes
How the work actually runs.
Scope is agreed in writing before the build starts, and every stage produces something you can inspect.
- 01
Architecture and rendering
What is static, what is server-rendered, what is client-side — decided per route against how the page is actually used.
- 02
Design system
Tokens, components and states, so the tenth page costs a fraction of the first and looks like it belongs.
- 03
Performance budgets
Explicit limits on bundle size, image weight and Core Web Vitals, verified before release rather than after complaints.
- 04
Accessibility
WCAG 2.2 AA as a build standard: semantics, keyboard operation, focus management and contrast.
- 05
Analytics and iteration
Instrumentation on the paths that matter, so the next round of changes is decided from behaviour rather than opinion.
Typical stack
- React
- Next.js
- TypeScript
- Tailwind CSS
- Node.js
- PostgreSQL
What you receive.
- Product and marketing front-ends
- Dashboards and customer portals
- Design systems and components
- Core Web Vitals budgets
- WCAG 2.2 AA accessibility
Straight answers.
- Can you work with our existing design?
- Yes. If you have brand guidelines or a design system we build to them. If you have a design that is causing the problem, we will say which parts and why before changing anything.
- Do you hand over the code?
- Always. The repository is yours throughout, hosted where you choose, with deployment documented so you are never locked to us.
- How fast is fast enough?
- We target Core Web Vitals in the 'good' band on a mid-range Android over 4G, not on a developer laptop. The specific budget is agreed during architecture and it is testable.
Other services
Need Web Applications? Tell us the problem.
The first conversation is about your operation, not our stack. If a smaller fix would do the job, we will say so before quoting a larger one.