Software projects fail commercially far more often than they fail technically. This process exists to remove the specific structures that cause that — open-ended billing, vague scope, and suppliers who become indispensable by accident.
You describe the problem in whatever language is natural to you. We ask questions and give you an honest first read: whether this is a software problem at all, roughly what solving it involves, and whether we are the right people for it.
A proper investigation. We map the current process end to end, interview the people who actually do the work, model the data, and identify where the money is genuinely leaking. This produces a written specification — and you own it whether or not you build with us.
Interface and interaction design for everything users will touch, reviewed with the people who will actually use it. Changing a screen at this stage costs an afternoon; changing it after it is built costs a sprint.
Development in visible increments. Work goes into a staging environment you can open at any time, so progress is something you observe rather than something you are told about in a status meeting. Automated tests and code review run on every change.
Data migration, user acceptance testing, training and a cutover plan with a rollback path. We do not do dramatic Friday-night switchovers if a phased transition is possible instead.
Source code, infrastructure definitions, credentials and documentation transferred to you. Support afterwards is available on a retainer, but the system is deliberately built so that you are not dependent on us for it to keep running.
Because it is real work with a real deliverable. Free "discovery" is a sales process that ends in a proposal, and the cost of it is priced into the build whether you see it or not. Paid discovery produces a specification, data model and architecture that you own outright — you can take it to other suppliers and get genuinely comparable quotes, which is uncomfortable for us and good for you.
You raise it, we price it, and you decide. Changes are normal and we do not treat them as a betrayal of the specification. What we will not do is absorb them silently and then quietly extend the timeline, or hold them against you at the end as a reason the project slipped.
Heavily during discovery — that is where your knowledge of the process is irreplaceable. Then a few hours a fortnight for demos and decisions during the build, rising again around user acceptance testing and training. Projects where the client disengages after kickoff consistently produce software nobody wants to use.
You keep everything produced up to that point — code, documentation, designs, infrastructure definitions — and you owe for work completed, not for the remainder of the contract. We would rather you stop a project that stopped making sense than spend the rest of the budget out of sunk-cost obligation.
Yes, routinely, and usually before the first discovery conversation gets into detail. Send yours or use ours.
No specification required, no preparation needed. Describe the problem and we will tell you what we think — including if we think you should not build anything.
