Service 02
Custom Software
Systems built for one organisation and one problem, where the off the shelf option would cost more in workarounds than the software costs to build.
- Capability 1
- Domain modelling
- Capability 2
- Backend
- Capability 3
- APIs
- Capability 4
- Testing
The approach
Custom software is the right answer less often than vendors claim and more often than procurement assumes. The test is whether your process is a genuine differentiator or an accident of history. We will help you work out which, including when the answer is to buy something instead.
When it is the right answer, most of the value is in the modelling. A domain modelled properly is a system that absorbs the next five years of change; one modelled badly needs a rewrite the first time the business does something new.
We write the architecture decisions down as we go, so the reasoning survives the people. That document is what lets a different team pick the system up in three years without reverse engineering your intent from the code.
- 01
Model the domain
Sessions with the people doing the work, not only the people specifying it. The gap between the two is usually where the requirements are.
- 02
Build against a trunk
Short increments on a deployable trunk. There is a running system from the first week and it never stops running.
- 03
Hand it over properly
Documentation, a runbook and time with your engineers. Handover is a phase with a date, not an email at the end.
What you get
Deliverables, not a status update.
- 01
Domain model
The nouns, the rules and the invariants, agreed with the people who actually do the work.
- 02
Working system
Interface, service, data layer and integrations, deployed and exercised, not a prototype.
- 03
Test suite
Unit, integration and end to end, running in CI, fast enough that people keep running it.
- 04
Architecture decision records
What was chosen, what was rejected, and under what conditions the decision should be revisited.
- 05
Runbook
How to deploy it, how to roll it back, what breaks first and what to look at when it does.
- 06
Handover
Source, infrastructure, credentials and an afternoon with your team. No dependency on us you did not choose.
Questions
Answered straight.
- Do you work alongside our team?
- Usually, and it is the better outcome. We are explicit about who owns what and we plan for your team to take it over.
- What happens to the code?
- It is yours, in your repository, from the first commit. Infrastructure and credentials are yours too.
- Can you take over an existing codebase?
- Yes. We start by reading it and writing characterisation tests before changing anything.
Start here
Have a custom software problem?
You will speak to an engineer, and you will leave the first conversation with an opinion about your problem whether or not you hire us.