Five stages, and what each one owes you.
Every stage ends with something you can read, use or sign. How long each one takes depends on what is being built; the order does not change, and neither does what you are owed at the end of it.
We agree what is being built, in writing
A working session on the problem, the must-haves, and the edge cases that decide whether this is a fortnight or a quarter. You leave with a plan in plain English, a fixed scope and a price, before anything is built. If the honest answer is that you do not need custom software, that is the answer you get.
It gets built in the open
The plan is built in short passes and deployed as it goes, so there is a working system to look at within days rather than a status report to read. The person who scoped it is the person writing it — nothing is re-explained to a second team, and nothing is lost between them.
Nothing ships on trust alone
Every change is reviewed and tested against the plan before it goes anywhere near your customers. You react to the real thing rather than a mock-up, which is the point of seeing it early: changes are cheap while the work is still moving and expensive once it has stopped.
It goes live in your name
Deployment is set up properly, documented, and run by pipeline rather than by hand. The repositories, hosting, domains and third-party accounts are yours, and the handover notes are written for whoever changes it next — on the assumption that it will not be me.
Someone who already knows the system
Businesses change and the software has to follow, whether that is a fix, a new feature or a phase two. You are not re-explaining how the business works to a stranger. If you would rather take it in-house, the handover is the same either way.
Projects rarely stall on the engineering. They stall waiting for a decision nobody is authorised to make, so it is worth being explicit about the short list.
One person who can decide
The projects that run fastest have a single person on your side who can settle a question without convening a meeting. Not necessarily the most senior one — the one who knows how the work actually gets done.
Access to the people doing the job
An hour with whoever currently lives in the spreadsheet is worth a week of guessing. They know the exceptions, and the exceptions are where software goes wrong.
Answers at the review points
Feedback while a decision is still open costs you minutes. The same feedback after launch costs a rebuild. Everything else can wait; these cannot.
Tell me what stage you are at.
A rough idea, a written spec, or a system already in trouble — half an hour on a call is usually enough to tell whether this is worth doing.