How I quote, and why the first number is usually wrong

Clients ask for a price before they finish describing the problem. I understand why: price is the easiest thing to compare across suppliers.

But a number given before the problem is understood has only two outcomes, and both are bad. Either it is padded to cover risk, and you pay for my uncertainty. Or it is thin to win the work, and the overruns arrive later.

The first session is free

Ninety minutes, and I deliberately sell nothing in it. The goal is to establish three things.

First, the real problem. What a client says they need and what they actually need are usually one step apart. Someone asks for a mobile app when what would fix their problem is repairing the data entry process on desktop.

Second, the constraints that cannot move. A date fixed by an event. A legacy system that must run in parallel for six months. Data that cannot leave servers inside the country. These shape the solution more than the feature list does.

Third, the real budget. Not to spend all of it, but to know whether the problem is solvable within it. If the budget is a tenth of what the problem needs, saying so in the first session is far better than discovering it in month two.

After that session you get a document

Not a deck. A few pages: the scope, a timeline in weeks, the team size, a price range, and an explicit list of what falls outside.

The out-of-scope list matters as much as the in-scope one. Most later disagreements come from things nobody mentioned at the start, not from things that were discussed.

The document does not commit you to anything, and you are welcome to take it to another supplier. I know some clients will do exactly that, and that is their right.

Why a range, not a number

At that point I know enough to give a range but not enough to commit to a number. The range is typically about thirty percent wide.

It narrows after the first two weeks, once I have read the real data, seen the current system, and spoken to the people who will use the software. That is when a fixed number goes into the contract.

Some clients dislike this because they want a number today. I understand, but I do not give numbers I do not believe.

Scope changes

Change is normal. How it is handled is what differs.

Every change is written down, estimated and priced before work happens. I do not build extra and invoice afterwards, and I do not quietly cut something else to make up the hours.

If you decide not to do it, the project continues on the original scope. No penalty, no attitude.