Web application development
We build web applications for businesses: customer portals, dashboards, internal tools and SaaS products. Most web applications are built and reviewed on new hardware, on office broadband, against a small test database. Then they meet a four-year-old laptop on hotel wifi, fifty thousand real records and a browser with twelve other tabs open. That gap is where web projects quietly lose their users, so we design for it from the first week rather than in an optimisation pass at the end.
Why it gets slow
Performance is not one problem, it is four, and they have different fixes. Treating it as a single task at the end of a project is why the task never gets done.
A single bundle containing every screen, every library and every locale, downloaded before anyone can click anything. Route-level splitting and honest dependency review usually recover more than any amount of micro-optimisation later.
Queries that are instant against a thousand test rows and pathological against a million real ones, usually because an index was never added or a loop is issuing a query per item. It is one of the most common reasons a page gets slower month by month.
Auth, then profile, then permissions, then content, each waiting for the last. Every round trip costs a fraction of a second that is invisible in the office and painful on mobile data.
Without real user monitoring you find out from a customer rather than a dashboard, and you are guessing about which page and which device. Measurement is what turns performance from an opinion into a task.
Budgets
A target nobody checks is a wish. We agree budgets with you at the start and wire them into continuous integration, so exceeding one fails the build in the same way a broken test does. These are our usual starting points. The two page-experience figures are the thresholds Google treats as good for Core Web Vitals.
| Metric | Budget | How it is measured |
|---|---|---|
| Server response | Under 200ms | Measured at the origin, before any content delivery network, so caching hides nothing. |
| Largest contentful paint | Under 2.5s | On a mid-range device over a throttled connection, not on the machine that built it. |
| Interaction to next paint | Under 200ms | Because an interface that responds late feels broken even when it is technically correct. |
| JavaScript shipped | Capped per route | A number agreed up front. Adding a library that breaks it becomes a conversation rather than a silent regression. |
Who it is for
Businesses whose customers, partners or staff do real work in a browser: ordering, approving, reporting and managing. If a site mainly needs to publish content, you need something simpler than what we build.
What we build
Dashboards, portals, internal tools and customer-facing products, built to stay fast as the data grows rather than only on launch day.
Budgets, profiling and the unglamorous database work that produces most of the real gains.
WCAG 2.2 AA as a build requirement, tested with real assistive technology rather than only an automated scan.
Live updates, presence and collaborative editing, with the conflict handling that makes them trustworthy.
Connecting to the systems your business already runs on, with contract tests so an upstream change fails in CI rather than in production.
Real user monitoring alongside synthetic tests, so you know what actual people experience on actual devices.
Their team was enthusiastic and delivered what they promised on time. And they easily responded to all our questions and changes throughout the process.
How we ship it faster
A web application is mostly surface area. Screens, forms, tables, filters, validation, empty states, error states, permissions on every route, and a test for each of them. It is well understood work that consumes most of a project budget without differentiating the product at all. We generate the first pass with AI tooling and put senior engineers on the data model, the performance work and the review, which is where a web application is actually won or lost. AI accelerates the work. Our engineers stay accountable for the decisions and the software that ships.
An indicative comparison, not a quote or a guarantee. The gain depends on your integrations, your data and how many roles and workflows the application has to support. We estimate every project individually and put scope, timeline and price in writing, with a like-for-like comparison against conventional delivery, before you commit.
Proof
The pages you are reading are hand-built on the same principles: no page builder, one stylesheet and very little JavaScript. We would rather you checked a performance claim than took it on trust, so open your browser’s developer tools and look at what this page loads and how long it takes.
Questions we get asked
Whichever suits the application and, importantly, whoever maintains it afterwards. React, Vue, Svelte, Laravel, Rails and Django are all in regular use here. A framework choice that leaves you unable to hire is a bad choice regardless of its technical merits, so your hiring market is part of the decision.
Usually, yes. We start with measurement rather than assumption, because the cause is rarely where people expect. The large wins tend to be a handful of database queries and an oversized JavaScript bundle, and both are normally fixable in weeks rather than by starting again.
It depends on the number of user roles, the integrations and how much data has to move across, so we do not publish a price list. Within a week of our first call you get a written approach with a cost and time range and the assumptions behind it. When you are ready, that becomes a fixed proposal with scope, price and milestones in writing.
Automated tools catch only part of what matters. We test keyboard paths and screen reader flows by hand as part of the build, because the failures that hurt most, such as a modal that traps focus or a form that gives no error context, are exactly the ones a scanner cannot see.
The budgets stay in your continuous integration pipeline. If a future change pushes response time or bundle size past the agreed limit, the build fails and somebody has to make a deliberate decision. That is what keeps performance from eroding quietly over two years.
Yes, and often that is the sensible scope. We will tell you honestly if the API design is going to limit what the front end can achieve, and what a minimal set of changes would make possible, rather than insisting on replacing something that works.
It depends whether the pages need to rank. Where they do, we server-render, keep the markup semantic and the metadata correct, and treat performance as the ranking factor it is. Where the application sits behind a login it does not matter and we will not sell you work you do not need.
We agree the matrix at the start based on your own analytics rather than a generic list. Supporting a browser nobody uses is a real cost, and so is dropping one that two percent of your revenue depends on, so the decision should be made against your data.
You do, in full, on final payment. Repository, infrastructure configuration, documentation and the freedom to hire anyone to continue. No minimum support term.
Related services
Related case studies
Next step
A senior engineer reads every enquiry and replies within one business day, with an honest first view on scope, the hard parts and whether your existing backend can stay.
Certified, partnered and awarded
1/7
Discuss your project
Seven short questions. About 90 seconds. A senior engineer reads your answers before we reply. No sales sequence, no newsletter. Just a thoughtful response about what comes next.
Start here
Choose the one that comes closest.
The problem
A sentence or two is enough. Tell us what isn’t working today or what you want to make possible.
Where you are today
Choose everything that applies.
Timing
A real deadline changes how we approach the work. If there isn’t one yet, that’s useful to know too.
Scope
A range is enough. It helps us understand the right approach and team for the problem. It does not determine what we charge.
Your team
This helps us understand whether we should lead the engineering, work alongside your team, or advise your existing engineers.
Stay in touch
A senior engineer will read what you’ve shared and respond within one business day.
How would you prefer to continue?
Received
A senior engineer will review what you’ve shared and come back with the most useful next step.