The quote is the hard part of the job

Every project I take runs on a fixed price agreed before the work starts. No hourly meter, no invoice that grows while the client watches it. Clients like this for the obvious reason. What is less obvious is what it does to me.

An hourly rate lets you start building before you understand the problem, because the meter absorbs whatever you find later. A fixed price does not. If I have misread the scope, that gap comes out of my time. So the quote has to be the most careful thinking I do on a project, and it happens before anybody has paid me anything.

What the call is for

The first call is twenty minutes and free. I am not pitching in it. I am trying to get three answers.

What the business goal behind the software is. Who touches it daily. And what happens to the client if it never exists. That last one sounds unkind and it is the most useful question on the list, because the answer tells me whether this is a project with a deadline attached to something happening or a project someone is thinking about.

A brief that cannot answer it is usually not ready to be quoted. I say so on the call rather than after the invoice.

Most feature lists are two lists

Almost every brief that arrives with a list of fifteen features is a list of three features and twelve things that can wait. The three decide whether the product works at all. The twelve are what people add when they are nervous about launching.

Sorting those before any code exists changes the outcome more than anything I do afterwards. It is also the part clients push back on hardest, because cutting a feature feels like losing something. It is not. Shipping in six weeks with three features that work beats shipping in five months with fifteen that nobody has used yet.

A fixed price is a promise about scope in both directions. It stops me padding the estimate and it stops the scope quietly doubling.

Where I have got it wrong

Twice now I have quoted a project on the assumption that the client had their content ready. Both times the build finished and then sat waiting for copy and images for weeks. The code was done and the project was not, and that time is not billable to anyone.

So content readiness is now a line in the proposal with a date against it. Not as a way of assigning blame later. As a way of surfacing, before anyone signs, that a website with no words in it is not a delivered website.

The other one I still get wrong sometimes is integrations. A payment gateway I have shipped four times takes a day. A gateway I have never touched, in a country whose rules I have not read, can take a week and I will not know which until I am in it. Now I quote those separately and say why.

The proposal

Within three days of the call the client gets a written document: fixed scope listed item by item, fixed price, timeline, and what is explicitly not included. The last section is the one that prevents arguments.

If the scope changes later, the price changes and we both know it changed, because the original list is written down. That is the whole mechanism. There is nothing sophisticated about it and it has removed almost every uncomfortable conversation I used to have about money.