Web applications for work that does not fit an off-the-shelf product. Client portals, booking systems, internal dashboards, and the integrations that keep them fed.
Almost every request starts the same way: a spreadsheet that four people need at once, or a process held together by somebody remembering to send an email.
One place your clients sign in to see their documents, their status and their invoices.
The spreadsheet that runs a critical process, rebuilt so two people can safely use it at once.
The plumbing between the products you already run, so the same figure is never typed twice.
Nothing is delivered as one release at the end. Each slice does a real job, so you find out early whether it fits how the work actually happens.
We map the process as it works now, including the parts that only live in somebody’s head, and agree what the first usable version has to do.
A clickable prototype of the core flow, put in front of the people who will use it daily before any of it is expensive to change.
Delivered in slices. Each one is tested, deployed to staging and genuinely usable rather than a demo of a screen.
Migration from the spreadsheet, training, monitoring and alerting, then changes as the process changes — because it will.
A website that breaks is embarrassing. An application that breaks stops people working, so the standards are different. None of these four are optional extras; they are the reason the thing is still running in year three.
Staging and production are separate from the first commit, and every database migration is reviewed and run somewhere else before it touches your live data.
Nothing reaches live that has not run somewhere else first.
No proprietary format and no lock-in. Every table comes out as CSV, on demand or on a schedule, whether or not we are still involved.
Exports are a built-in feature, not a support request.
Who changed what, when, and what it was before — recorded on the records where that question gets asked months after the fact.
Answerable later, not only while someone still remembers.
Source code, deployment pipeline, environment configuration and technical documentation, in accounts owned by your company.
Another developer can pick it up without calling us.
Discovery is the cheap place to find things out. Bring the awkward questions there.
No. It runs in the browser and works on a phone, which covers almost every internal tool and client portal without the cost of two native builds and two app store review queues.
If your case genuinely needs a native app — offline use, camera or hardware access, push notifications as the core mechanic — we will say so rather than talk you into the web.
Usually, yes. If the product has a documented API or webhooks, we integrate with it. If it does not, we look at scheduled exports and imports instead, which is slower but honest.
We check this in discovery, before anything is committed, because ‘it has an API’ and ‘it has an API that does what you need’ are different claims.
Hosting, the database, file storage and any third-party services it depends on. We put the expected monthly running cost in writing before the build starts, and we size the infrastructure for what you actually have rather than for a launch that might not come.
It is almost always less than the seats you are currently paying for across several products.
You do. The repository, the pipeline and the infrastructure accounts are in your company’s name, and the handover includes the documentation another developer would need to take over.
We would rather you stay because the work is good than because leaving is difficult.
Describe the work you are trying to replace. A plan and a fixed figure follow inside one business day.