Why we agree the price at step three, not step one
Most software quotes are an estimate of something nobody has looked at yet. We hold the number back until the analysis is done, and here is what that changes.
The first question on almost every first call is what it will cost. It is a fair question, and the honest answer at that moment is that nobody knows - including us. What we have been asked to price is a description of a problem, not a defined piece of work, and the gap between those two things is where software budgets go to die.
So we answer it twice. On the first call you get a range and the reasoning behind it. The number that goes in a contract comes later, at step three of the Schtelbe model, once the analysis and the concept are done.
What a step-one price is actually measuring
A quote given before any analysis is a measurement of how confident the person quoting feels. It is not dishonest; it is just made of assumptions that nobody has tested yet - about the systems the software has to talk to, about how the work is really done on the floor as opposed to in the process document, and about how much of what was asked for is needed at all.
Those assumptions get tested eventually. They get tested during the build, which is the most expensive moment to find out that one of them was wrong. And at that point the project has only two moves left: the price changes, or the scope quietly shrinks until it fits the price. Both of them damage the relationship, and the second one is worse, because it is the one nobody announces.
What changes when you move it to step three
By step three the analysis is done and the concept has been visualised and reviewed - including by someone who has actually done the job the software is meant to support. Three things are true that were not true on the first call:
- The integrations are known. The question is no longer whether a system has an API, but what that API will and will not do.
- The scope has usually shrunk. Nearly every discovery turns up something in the original request that is cheaper to solve without software, and something else that turns out to matter far more than anyone said.
- Budget, technical scope and deadline are agreed together, in one conversation, rather than one of them being fixed in advance and the other two bending to meet it.
That last point is the one that matters most. A price agreed on its own is a number that scope and schedule then have to serve. A price agreed alongside them is a decision about a specific piece of work, and that is a thing you can hold us to.
What it costs you
This is slower at the start. You do not leave the first meeting with a figure for the board, and if you are comparing three suppliers, the other two will probably hand you one. We would rather be the slow quote than the one that moves.
It also means the analysis work is real work, and it is scoped and agreed as such. The point is not that discovery is free - it is that you are not committing to a build budget before the discovery that defines it has happened.
Where it came from
Mostly from projects where the opposite happened. The pattern is consistent enough that we built the sequence around it: six steps, and the commercial commitment sits at the third rather than the first.
It is not the right model for every piece of work. If you need a known thing built to a known specification, a price on day one is reasonable and we will give you one. It is the right model for the projects where nobody yet agrees on what the problem is - which, in our experience, is most of them.