Service
Custom software
Systems built for how your organisation actually works, including the parts that do not fit a product.
At a glance
- Typical timeline
- Three months for a bounded system; a year or more for a platform replacing several
- Indicative price
- Pending commercial sign-off · see engagement models
- Stack we default to
- TypeScript
- Go
- .NET
- PostgreSQL
- Kubernetes
- Terraform
- Engagement models
- Time and materials
- Dedicated team
- Outcome-based
The problem this addresses
Off-the-shelf software covers the common ninety percent. The remaining ten percent is usually where the competitive advantage lives, and it is the part that ends up in spreadsheets and manual workarounds.
What you get
- 01A system covering the workflow that no product on the market covers
- 02Integrations with the products you keep, built to survive their upgrades
- 03Migration of the data currently living in spreadsheets and inboxes
- 04Operational tooling — the admin views and reports that make it supportable
- 05Training and documentation for the people who will run it
How the work runs
- 01
Workflow discovery
We sit with the people doing the work. The documented process and the actual process are rarely the same, and the difference is usually where the requirements are.
- 02
Boundary design
We decide explicitly what to build, what to buy, and what to leave manual. Building less is usually the better answer.
- 03
Iterative delivery
Two-week iterations, with real users of the system in the review each time.
- 04
Operational handover
Runbooks, monitoring, and a support model agreed before we roll off.
Where this fits
This is the broadest of the four services, and often the right starting point when the problem does not decompose neatly into "a web app" or "a mobile app". E-commerce platforms and long-term maintenance engagements both sit here.
Build less
The single most valuable thing we do on these engagements is talk clients out of scope. A system that covers the genuinely differentiated ten percent and integrates cleanly with bought components for the rest will be cheaper to build, cheaper to run, and easier to hire for than one that reimplements authentication and billing badly.
Proof
Work delivered with this service
Saltea
Rebuilding subscription billing and entitlements at Saltea
Every price change at Saltea needed an engineering release, and mid-cycle plan changes were priced three different ways. We moved pricing out of the application and rebuilt the billing surface on top of it.
Zafarin
Closing the daily reconciliation break queue at Zafarin
Zafarin's daily safeguarding reconciliation produced a queue of breaks that finance operations cleared by hand every evening, and the queue grew with transaction volume. We rebuilt the partner feeds, the ledger and the break workbench underneath it.
Questions
What clients ask before starting
How do you decide what to build versus buy?
We look for whether the capability is a differentiator or a commodity. Commodity capabilities — authentication, payments, email delivery, document storage — should almost always be bought. Differentiators, and the integration glue between bought components, are where custom work pays for itself. We will argue you out of building things you can buy.
What happens to our existing systems?
Usually they stay, at least at first. Replacing everything at once is the most expensive and riskiest possible sequencing. We prefer to put a boundary around the legacy system, build alongside it, and retire it in pieces once the replacement is proven.
Who owns the intellectual property?
You do, from the first commit. Code is written in your repositories under your organisation. We retain no licence and nothing is dependent on a component we control.
Can you take over a system another vendor built?
Yes, and it is a common starting point. We begin with a technical audit, a description of the current state and the risks in it, and an honest assessment of whether continuing is cheaper than replacing. Sometimes the answer is that you should replace it, and we will say so.
