Custom Software, SaaS & MVPs
Systems built to be handed over.
Internal tools, APIs and data platforms. We write the boring parts properly — migrations, observability, tests around the logic that would cost you money if it broke — so the thing survives the first year.
Migrations, logging and tests written first, not last
How we think about it
Most internal software fails slowly: it works at handover, then decays because nobody can see what it is doing or safely change it. The boring parts — migrations, logging, tests around the logic that moves money — are what decide whether a system is still usable in its second year. We write those first, not last.
When the same team builds the interface and the hardware talking to it, the API stops being a negotiated boundary and starts being a design decision.
What this covers
The work, specifically.
- 01
TypeScript
End to end, with the type boundary at the edges where data actually enters the system.
- 02
Python
Data work, automation and services, where the ecosystem earns its place.
- 03
Postgres
Reviewed schemas and reversible migrations. The database outlives the application.
- 04
Event pipelines
Queues and scheduled work that can be replayed, inspected, and safely retried.
- 05
Cloud infra
Infrastructure as code, with logs and alerts you can read without our help.
Need Custom Software, SaaS & MVPs for something specific?
Tell us what you're trying to ship and we'll say plainly whether this is the right service for it — including when the answer is no.
How it runs
The same four steps, whatever we're building.
No account-manager relay. The lead on your project is someone who builds, and they stay on it from the first call to the last deploy.
Scope
A week of hard questions. We map what you actually need and say plainly which parts we'd cut.
Prototype
Something real in front of you early, not a document about it. Opinions get cheaper.
Build
Two-week cycles, a demo at the end of each. You see progress, not status reports.
Hand over
Documentation, a walkthrough, and the keys. Support if you want it — never as a hostage.
Questions
The things people ask before they enquire.
Entirely. Code, repositories, infrastructure accounts and documentation are yours from the start, not transferred at the end. You are never in a position where leaving us means losing the product.
Usually, yes. We start by reading what is already there rather than proposing a rewrite. Rewrites get recommended when the existing system genuinely cannot carry the next requirement — and we will show you why before you spend anything.
It depends on scope, but we will give you a number before you commit to anything. Most engagements start with a paid discovery — a fixed fee, a week or two — which ends in a written scope and a real budget. If the budget does not work, you leave with the scope document and no obligation to continue.
A typical first ship is around six weeks. Larger builds run in two-week cycles after that, each ending in a demo of something that actually runs. You will know within the first cycle whether the timeline is holding, rather than finding out near the deadline.
The people you meet. The lead on your project is someone who builds, and they stay on it from the first call to the last deploy. There is no account manager relaying messages between you and an unseen team.
You own everything — code, assets, accounts, domains. We hand over with documentation and a walkthrough, and your team can run it without calling us. If you would rather we stayed on for maintenance or a next phase, that is a separate agreement, not something buried in the original contract.
Yes. Most of our work is remote, and we keep a few hours of overlap with your working day for calls. Timezone has not been the hard part; unclear scope has.
Where it meets the others