• consultancy
  • engineering-leadership
  • founders

How to evaluate a software development quote in an hour

6 min readSimon Piscitelli
How to evaluate a software development quote: a tape measure pulled taut across a doorway with its markings worn off.

Three software development quotes for the same brief, and the highest is three times the lowest. Nothing in any of the documents explains the gap. A decision is due this month, and there is nothing on the desk to evaluate them with except price and instinct.

Stop trying to judge the number. You cannot evaluate an estimate you could not have produced yourself, so evaluate what the quote refuses to name instead. Five things: the scope boundary, who decides when reality disagrees with the plan, what the price assumes about your side, how change gets priced, and what you own at the end. A quote can be wrong about the number and still be safe to sign, while one missing two of those five is not a price but a placeholder you will renegotiate under pressure, from a worse position.

An hour with the documents settles most of this, and you can do it alone.

The five things every quote must name

1. What is explicitly not included. Written by them, not inferred by you from silence. A quote with no exclusions has been priced rather than thought about. Exclusions are evidence somebody imagined the work going badly.

2. Who decides when the plan meets reality. A person with a name, not a process with a diagram. Plans meet reality on every build I have run, and someone makes the call that day. Ask what happens when they are unavailable.

3. What the price assumes about you. Access, decisions, content, testing and sign-off, each with a turnaround time attached. This is where overruns are born, and the line I most often find missing.

4. How a change is priced, and who approves it. Settled in the document, before the first change, rather than in the argument the first change causes. Two lines are enough. Their absence is not neutral.

5. What you own at the end. Code, infrastructure, accounts, credentials, documentation, and whether anybody other than them can run it on a Monday morning. Ownership is a commercial term, and the only one on this list a lawyer will read and an engineer will not.

Every one is checkable against the document itself. None requires an engineer, because the subject is the document, not the engineering behind it.

What each missing line costs you

Missing exclusions become change requests at the supplier’s discretion, surfacing at the worst point in the schedule, after you have given a customer a date, or the board a quarter.

No named decision owner routes every ambiguity back to you. That is the exact cost you were paying somebody else to carry.

Unstated assumptions about your side turn into a delay attributed to you, and attribution decides who pays. No change mechanism converts every disagreement into a relationship problem rather than a contractual one, settled by whoever has the stronger hand. Once the deposit has cleared, that is not you.

Unclear ownership is the expensive one. It decides whether leaving ever means rebuilding from scratch, and on the day you sign it is priced at zero.

The builds I run start by writing down what the quote does not say. The overruns I have watched came out of a sentence nobody wrote, not a number nobody checked.

How do you compare two quotes that differ by a factor of three?

Do not normalise the numbers. Put the documents side by side against the five points and the gap usually explains itself: the cheap one is cheap because it excludes what the expensive one includes, and the exclusion is unwritten in both.

Then send both suppliers the same three questions in writing. What is out of scope. What do you need from us, and by when. What do we own on the day the final invoice is paid.

Compare the replies, not the totals. A firm that answers inside a day, in specifics, is showing you how it will behave in week nine. A firm that answers in a fortnight, in adjectives, is showing you that too.

Do not go looking for a villain. A quote missing four of the five reads to me as an honest firm with a weak sales process, and the repair is a conversation rather than a different supplier. The gap is rarely a competent builder. It is that nobody on your side is paid to own the technical decisions the document quietly makes for you.

Why trust a checklist about somebody else’s quote?

A checklist like this is worth more from somebody with no bid in front of you. I have none, though I have written plenty from the supplier’s side and delivered the work behind them. One MVP I built end to end on my own, while the founder sold it in discovery calls, reached a signed letter of intent and a pilot agreement inside three months. I know what a quote leaves out because I have had to price the same work honestly.

The reading leads three ways, and I have a stake in two of them. Sometimes the document is sound and you sign it. Sometimes the scope is wrong and the work needs redefining before anybody prices it. Sometimes the supplier is not the gap at all: nobody in the business holds the technical decisions, and the next thing I do is hold them, whether that means running the team that ships the work or writing it.

Which one it is decides what you buy next. Judging a document and how to judge the person when you cannot judge the work are different jobs, and the second turns on the difference between a supplier who prices the work and a person who carries it. What comes off the bill in the first quarter is rarely negotiated off a rate. It is work that stops being bought by accident, once somebody owns the decision behind it.

How to evaluate a software development quote before you sign

One hour on the document. One written round of questions. Then decide.

Anything more elaborate is delay dressed as diligence, and the money is already committed in your head. If all five are named and the answers come back specific, sign it. Plenty of quotes pass this hour. Once the work starts the discipline moves from the document to the delivery, where the four questions that separate a busy team from a productive one take over.

The harder case is when the document is fine and the work it prices is not. The Technical/Strategic Review answers one decision in writing, yours to keep; what a two-week written verdict covers is set out in full. If your deposit is days away, this is not that: read the document yourself and push the supplier on the gaps. If you are unsure whether to buy this build at all, book the exploratory call.

Three answers are on the table: sign it, send it back with questions, or stop and ask whether this is the right work at all. The cheapest hour anybody will ever spend on this document is the one before the money clears. After that, every line the quote never named becomes a negotiation you open from behind.

If the decision is live

The Technical/Strategic Review answers it in writing in two weeks: one senior technology director inside your codebase, team and roadmap, then a verdict you own outright. Fixed fee, agreed on the exploratory call, credited against the engagement that follows. How it starts

Book the exploratory call