What should you check before signing a software quote?
Five things that decide whether a build goes well. None of them is the price.
The short answer
Before signing a website, app or software quote, get five things in writing: what is explicitly excluded, who will actually build it, what happens when the scope moves, what it costs to run after launch, and what you own at the end. Price is the easiest of the six numbers to compare and the least predictive of the outcome — most projects that go wrong were quoted accurately and scoped badly. A firm that answers all five quickly and in writing has usually done this before; one that keeps routing you back into a meeting is managing you.
What is excluded?
Ask for the exclusions, not the inclusions. Every proposal lists what is included, because that is the sales document; the second invoice comes from what nobody wrote down.
The usual omissions: content writing and migration, images and licensing, integrations with systems you have not mentioned yet, data cleaning, training your team, and fixes after the warranty period. None of those is unreasonable to charge for. All of them are unreasonable to discover in month two.
A good test: ask what the three commonest change requests are on projects like yours, and what each typically costs. A firm that has delivered this before answers immediately.
Who is actually going to build it?
The gap between the person selling and the person building is where most disappointment lives. It is entirely normal in this industry for the senior engineer on the call to be unavailable by the time work starts.
Ask to speak to whoever will write the code, before you sign. Ask how many other projects that person is on. If the answer is vague, price the risk in — or ask for the name of the lead engineer to be written into the agreement.
What happens when the scope moves?
It will move. You will see the thing working and want it different, which is not a failure — it is the point of building software rather than buying it.
What you need is a named process: changes quoted separately, in writing, agreed before they are built. What you do not want is goodwill, which runs out precisely when the project is under pressure, or a fixed price so rigid that every improvement becomes a negotiation.
What does it cost to run?
A build price with no running cost beside it is half an answer. Hosting, domains, certificates, licences, model and API spend if there is AI in it, monitoring, and somebody to call when it breaks at 9pm.
For most business websites this is small and boring. For anything with AI in it, it is neither: model spend scales with use, and a system nobody modelled can quietly cost more per month than the build did. Ask for the monthly figure at the volume you actually expect, and ask what happens if usage triples.
What do you own at the end?
- The code, in a repository you control — not a zip file sent on request.
- The hosting, domain and DNS accounts, in your name and not the agency’s.
- The analytics, search console and ad accounts, same rule.
- The design files, and the right to use them elsewhere.
- The content, including anything written for you.
If any answer here is vague, the answer is no. This is the single commonest way a business ends up unable to leave a supplier it has outgrown.
And the question that reveals the most
"What will I be able to look at in week one?"
A firm that ships something touchable early is a firm whose estimate you can check. A firm whose first deliverable is a document in week three is asking you to take the timeline on faith, and that is where overruns hide — nobody finds out the plan was wrong until most of the budget has gone.
It is also the cheapest protection available. If what comes back in week one is wrong, you have lost a week.
Questions this raises
Should I just pick the cheapest quote?
Only if the scopes are genuinely identical, which they almost never are. Compare the exclusions rather than the totals: the cheaper quote is usually cheaper because something you assumed was included is not. A quote that is dramatically lower than the others is normally a different piece of work wearing the same title.
Is a fixed price better than time and materials?
For work whose shape is understood, fixed price is better for you — the delivery risk sits with the supplier and you can plan. For genuinely exploratory work, a fixed price either carries a large risk premium or quietly narrows the scope. Fixed price per stage, with each stage small enough to be understood before it is priced, is usually the honest middle.
How much should I pay upfront?
Staged against milestones is normal: something to start, something at a visible milestone like design sign-off or a working beta, the balance at launch. What is not normal is the full amount before anything exists, or a schedule with no deliverable attached to any payment.
What if they will not put the timeline in writing?
Then it is not a timeline, it is a hope. Any supplier who has delivered comparable work can commit to dates for the stages they control, and name the things they do not control — your approvals, your data, your systems access — which is what usually moves the date anyway.
This is what we do about it
More like this
What actually breaks an AI agent in production
The failure modes, in the order we have met them — and almost none of them are the model being wrong.
How to cost an AI automation before you build it
Four lines of arithmetic that decide whether a project is worth funding — and that most proposals skip.
Why your RAG system should refuse more often
A retrieval system that never says “I don’t know” is not accurate. It is unmeasured.