The first version
A working product in weeks, not in a year.
A fixed scope and a fixed price, agreed before the first line of code, and at the end you have something in daily use rather than a presentation about what will exist one day.
What you receive
What is in your hands at the end.
- The product, released. At a real address with real users, not on a machine of ours kept for demonstrations.
- The code and the repository. Yours from day one, with a change history somebody can actually read.
- An environment built from a description. Any other team could rebuild it from that alone.
- The decisions, written down. Why it is this way and not another, so nobody rediscovers it in a year.
Nothing holds you here afterwards. That is deliberate, and it is in the contract.
The problem
First versions fail in one particular way.
The scope grows while nobody is counting. Each addition looks small on its own, and by the time they are added up the date has moved for the third time, with half the budget spent on things no user asked for.
So the scope here is closed in writing before anything starts, and anything asked for after that is priced on its own before anybody starts it. Without that, a fixed price is a number somebody hopes to keep.
The order
How the package runs.
- Closing the scope. If you came through the discovery sprint, this is already done and its price comes off. If not, it happens here.
- Sprint by sprint, every two weeks. At the end of each you see something working and say whether the direction is right.
- Released to people outside the studio. The moment there is something worth using, rather than on the final day.
- Handover. Access, documentation, the environment, and half a day with your own engineer if you have one.
The price and its limits are written down before the work begins.
The price is fixed against the closed scope, and a change is priced in writing before it is started, with your word on whether it goes in. Nothing is absorbed silently and nothing appears on an invoice as a surprise. The four shapes an engagement can take are set out on their own page, together with what moves a number.
Anything broken in what we built comes back to us at our own cost. The contract names how long that runs, counted from handover.
The questions
The six that decide it.
- How long does it take? It depends on the scope, and the package is built to be measured in weeks. Anyone who gives you a number before they have seen the scope has guessed at it, and you will pay for the guess later.
- What does it cost? A fixed price against a closed scope. The band comes in writing when you ask. Before that we need to know what we are building.
- Who owns the code? You do, from day one. You own the repository itself, not a login to ours.
- What if we want a change midway? We will price it and put it to you in writing. Small things often go in at no cost. Large ones we do not pretend are small.
- What happens after release? You continue alone, or take a support plan, or we become your product partner. All three are ordinary next steps.
- Who builds it? The team you met in the conversations, and it stays on the work until handover. Where a narrow specialism is required it comes through a named partner, agreed before the start rather than after it.
The beginning
Close the scope.
If you have no scope yet, start with the discovery sprint. If you have one, write directly.