Application developmentThe spreadsheet has fourteen tabs.Which one is the product?
Application development is everything past a brochure site: signed-in accounts, a database that models how the business actually works, integrations with the tools your team already runs, and an interface people use daily rather than visit once. Built as a typed codebase with tests and a deploy pipeline.
Why it matters
Every business eventually outgrows the file everyone edits at once. What replaces it decides how the next five years of work feel.
The model is the product
What is stored, who may see it and what the system may decide alone is agreed and written down before a screen exists. Everything expensive to change later is decided here.
Shipped in slices
One complete feature at a time, deployed and usable. If the budget stops halfway you have half a working application, not a whole unfinished one.
Yours to leave with
Your repository from the first commit, your infrastructure accounts, written documentation. Another developer can pick it up without calling us.
Where applications go wrong
Most failed builds are not failed code. They are a data model agreed in a meeting nobody wrote down, a permission rule that lived in one developer’s head, and a feature list that grew faster than anyone could test.
So the modelling comes first and is written down, the permissions are part of the schema rather than a check bolted onto each screen, and every slice ships deployed. If the budget stops halfway, you have half a working application instead of a whole unfinished one.
See pricing for how engagements are scoped and what the phases include.
How we do it
How the work runs.
- Model
- Prototype
- Build
- Harden
- Hand over
Model
What the application stores, who may see it, and which decisions it is allowed to make on its own.
Prototype
The two or three screens the work actually happens on, clickable, before the rest is built around them.
Build
Vertical slices — one complete feature at a time, deployed and usable, rather than a big reveal at the end.
Harden
Permissions, failure states, backups and load. The unglamorous half that decides whether it survives contact.
Built with
What this service is made of.
Interface
TypeScript
One language from the database call to the button, with the types checked at the boundary between them.
React
For interfaces with state worth managing — anything signed in, live or multi-step.
Tailwind CSS
A spacing and colour scale that holds across a large application without a stylesheet nobody dares delete from.
Application
Next.js
Server rendering, routing and server-side data access in one framework, so permissions are checked on the server.
Node.js
The runtime everything else assumes, and the same language the interface is written in.
Data
PostgreSQL
Relational, boring and correct. Tenant isolation and constraints belong here rather than in application code.
Prisma
Schema as a file in the repository, with migrations reviewed like any other change.
Delivery
GitHub Actions
Tests, type checks and the performance and accessibility gates run on every push, not before a launch.
Playwright
The handful of journeys that must never break — sign-up, checkout, enquiry — tested in a real browser.
Docker
The same environment locally and in production, so "it works on my machine" stops being a category of bug.
Cloudflare
Edge caching, DNS and protection in front of everything we host.
Application development — web and mobile FAQs
Still have questions?The ones we get asked.
How is this different from the website service?
A website is read: pages are generated ahead of time and served as HTML. An application is used: it has accounts, stores what people do, enforces who may do it, and changes state. The two are built with different trade-offs, which is why they are quoted separately even when they ship as one product.
Do you build mobile apps as well?
We build for the browser first, because one codebase covers every device and nothing waits on an app-store review. Where a native app is genuinely required — offline use, push, camera or hardware access — it is built from the same TypeScript codebase rather than as a second product to maintain.
Who owns the code?
You do. The repository is yours from the first commit, hosted in your organisation, with our access removable at any time. Handover includes the deploy pipeline, the environment variables and a written account of how the parts fit together, so another developer can pick it up without calling us.
Can you take over an application someone else built?
Often, yes. We start with a short read of the codebase and report honestly on what is worth keeping, what needs replacing and what it would cost either way. A rewrite is sometimes the right answer and is never the automatic one.
Start with application development?
Tell us what you are trying to grow. We reply with what we would change first.