How to read a software quote

For most business owners a software quote is a document with exactly one line they truly understand: the number at the bottom. The rest is a mix of jargon and assumptions you cannot argue with, because you do not know what normal looks like. That is uncomfortable, because you still sign it.

I write quotes myself and over the years I have seen plenty from other people. What a quote really is, is an agreement about expectations. The number is only the consequence of that. If the expectations are sharp, the number falls into place and you both know where you stand. If they are vague, the price is a starting point for discussions you will have later, usually at the worst possible moment.

What is in my quotes

My quotes have a clear scope, concrete deliverables and a fixed price. No padded hours.

Scope means: what are we going to make, and just as important, what are we not going to make. That second part feels strange to put on paper and it is exactly the part that prevents arguments later. Deliverables means: what do you hold in your hands when it is done. Not “a solution”, but the things you can point at and use.

The fixed price is a deliberate choice, not a sales trick. With a fixed price, the risk of a wrong estimate shifts to me. If something turns out to be more work than I thought, that is my arithmetic being off, not your invoice growing. With an hourly rate it works the other way around: the worse the estimate, the more gets paid, and you are the one least able to judge whether those hours were needed. That is not a pleasant split for someone who does not look at code every day.

There is also a side to it that gets mentioned less often. A fixed price forces me to think properly, up front, about what has to be built and what can be left out. That is the same judgement call that returns all day during the build: can I ship something that adds enough value today, or is time about to go into something nobody will use. An hourly rate never has to answer that question.

What happens when you change your mind along the way

This is the question everyone asks the moment the word “fixed” comes up. Fairly so, because plans always change. You start using the product, you talk to customers, and something turns out to need to be different from what you expected.

I use a simple distinction for that. If the change fits the direction we agreed on, we pivot within the scope. That is part of the job and I am not going to invoice for it. If it is a different direction, or something considerably larger than what we agreed, then we adjust the scope and the price.

That is not a penalty system, it is bookkeeping. If you decide halfway through that a whole new part has to be added, that is often a perfectly good decision for your business. It is simply not the work we agreed a price for. Making that explicit means nobody has to pretend, and the agreement keeps matching what is actually happening.

What helps here is having that direction clear up front. Not the screens, but the problem we are solving. When both sides know why something is being built, it usually takes a couple of minutes to tell whether a new wish fits the direction or is something new.

Two lines I look at immediately

In other people’s quotes there are two things that raise a question with me right away.

The first is a vague line that just says “development”, with a large number next to it. That is not an agreement, that is an amount with a label on it. You cannot check what is in it, you cannot establish when it is finished, and afterwards you cannot point at what you actually received. If you see a line like that, ask what falls under it and what falls explicitly outside it. A good answer costs the other person five minutes. If the answer stays vague, the scope itself is vague, and that is a bigger problem than the price.

A quote you cannot check is not a quote, it is an intention.

The second is hidden monthly fees. Licences, hosting, maintenance contracts, management subscriptions. There is nothing wrong with those in themselves, because some of those costs are real. The problem is that they sometimes sit small and near the back of the document while they run for years, and then the picture changes quite a bit. Add them up over three years and put that number next to the build cost. Only then do you know what you are really comparing.

Ask what happens if you stop paying, too. Does your site or app keep running, can you take everything to someone else, and whose name is on the domain, the hosting and the code? Those are not suspicious questions, they are the same questions you would ask any supplier.

Comparing quotes without understanding the technology

You do not have to be a developer to put two quotes side by side. You just need a different yardstick than the final number.

Look at which of the two tells you exactly what you get. Look at which one dares to write down what is not included. Look at how each of them handles changes, because you will end up there for certain. And look at whether anyone wrote anything about the problem you wanted to solve, or whether the quote only reflects your wish list back at you with amounts attached.

The cheapest quote is often the one with the fewest details, simply because less has been counted in. That difference comes back later, only then it is called additional work.

If you have a quote in front of you that you cannot quite make sense of, send it over. I will tell you where I would ask questions, even if the work ends up going to someone else.