Web application development
The demo works because it has forty rows in it. The question that decides whether a web application is any good is what it does at four hundred thousand rows, on a laptop that is five years old, over a connection that drops.
Where web applications actually break
Almost never in the framework. They break at the boundary between the interface and the data: a table that loads everything before it renders anything, a filter that runs a query per keystroke, a dashboard that recalculates six aggregates on every page load because nobody decided what could be cached.
The second failure mode is permissions. A system built without a real access model grows one accidentally, as a series of conditional checks scattered through the interface. Then somebody sees a page they should not, and the fix is a rewrite of everything that touches authorisation.
How we build them
Rendering strategy is a decision, not a default. Content that is the same for everyone is rendered at build time and served from a CDN. Content that is per-user is rendered on the server, close to the database. Only the genuinely interactive parts ship JavaScript. That split is why our pages tend to pass Core Web Vitals without a performance sprint at the end.
Access control lives in one place — a policy layer the data access goes through, not a set of checks in the interface. If a rule changes, it changes once. Every list endpoint is paginated by default and every filter is backed by an index that exists on purpose.
And the interface is built from a design system first. Building screens first produces a component library by accident, which means forty-four slightly different buttons and a redesign in eighteen months.
What we mean by an internal tool
Internal tools get treated as second-class and it is a false economy. The operations team uses that screen four hundred times a day; a two-second delay is fifteen minutes of their day, every day. We build internal tools with the same seriousness as the customer-facing product, and usually with more keyboard shortcuts.
They also tend to be where the real business rules are. If you want to know how a company actually works, read its admin panel, not its marketing site.
What this actually covers
Operational dashboards
Dense, fast, keyboard-navigable screens for people who live in them all day. Server-side filtering, real pagination, saved views.
Customer and partner portals
Self-service surfaces with a real permission model, an audit trail and an invite flow that does not email passwords.
Internal admin systems
The screens your operations team lives in. Built with the same care as the customer-facing product, because they carry the business rules.
Progressive web apps
Installable, offline-tolerant web apps where a native shell would add cost without adding capability.
Performance work
Core Web Vitals as an engineering constraint from the first commit, not a report someone runs the week before launch.
Accessibility
Keyboard paths, focus management and contrast checked as part of review. WCAG 2.2 AA as the working target.
The sequence
Same shape on every engagement, so you always know what week you are in and what happens next.
Map the screens against the data
Every screen is traced back to the queries behind it before it is designed. A screen that needs six joins to render is a modelling question, not a front-end one.
Design system, then screens
Tokens, primitives and patterns first. Screens assembled from them second. This is the difference between a product that stays coherent and one that drifts.
Build against realistic volumes
The development database is seeded with production-scale data from the start, so a slow query is caught the day it is written rather than the week after launch.
Instrument, then ship
Real user monitoring and error tracking are wired before the first release, not after the first incident.
Handed over, in your accounts
Not a demo and a login. These are the artefacts you keep, and they are what makes leaving us possible.
- A component library and design tokens, documented and used by the app itself
- Server-rendered pages with a deliberate caching and revalidation strategy
- A single authorisation policy layer, with tests for each role
- Core Web Vitals budgets enforced in CI, so a regression fails the build
- Keyboard and screen-reader paths through every primary flow
- Seed and fixture data so a new developer is productive on day one
Typically built with
- React
- Next.js
- TypeScript
- Astro
- PostgreSQL
- Prisma
- Tailwind
- Playwright
The selection principle is deliberately dull: largest hiring pool, longest support window. See why we choose these.
Web Applications, answered
The things people ask on the first call, written down so you do not have to.
Should this be a web app or a mobile app?
If your users are at a desk, or the task involves typing anything substantial, it is a web app — and installing it as a PWA covers most of what people think they need an app store for. You need a native or React Native app when you need real background execution, push notifications people will actually receive, offline-first sync, or hardware access like barcode scanning at speed. We will tell you which before you commit a budget, because building the wrong one is an expensive way to find out.
Do you use React and Next.js for everything?
No. Next.js is the default for applications with substantial interactivity and per-user data. For content-led sites — marketing, documentation, publishing — we usually reach for Astro, which ships almost no JavaScript and is materially faster for that job. This site is built with it. The right question is which rendering strategy the content needs, and the framework follows from that answer.
Can you make our existing web application faster?
Usually, and the first step is measurement rather than optimisation. We profile the real bottleneck — it is almost always database queries or an oversized JavaScript bundle, and the two need completely different fixes. You get a written assessment with the specific problems ranked by cost to fix against time saved. Some of them you can do yourselves, and we will say which.
How do you handle user roles and permissions?
With a single policy layer that all data access passes through, rather than conditional checks scattered through the interface. Roles are defined in one place, each one has tests, and the interface asks the policy layer what to show rather than deciding for itself. This costs a little more in week two and saves a great deal in year two, when someone asks for a role that can see nine of the eleven columns.
What about Core Web Vitals and SEO?
They are build constraints here, not a post-launch audit. Rendering strategy is decided per route, image handling and font loading are set up once and correctly, and performance budgets run in CI so a regression fails the build rather than being discovered by Search Console eight weeks later. For content-led sites we also handle the structured data and the internal link architecture, which is usually worth more than the last two hundred milliseconds.
What usually comes with this
- BuildCustom Software DevelopmentCustom platforms, marketplaces and SaaS. We write the parts that are specific to your business and buy the parts that aren’t.Read more
- GrowUI/UX DesignProduct design and design systems. Usually the first thing that turns out to be wrong, and the cheapest thing to fix.Read more
- RunCloud & DevOpsDeploys that are boring on purpose. Infrastructure as code, real environments, and a bill you can read line by line.Read more
- RunQA & Software TestingAutomated regression suites where they pay for themselves, and exploratory testing where they don’t. We tell you which is which.Read more
Thinking about web applications?
Start with a call rather than a brief. Thirty minutes, no deck, and an honest answer about whether we are the right people for it.