How to read a technical proposal when you can't read code

Almost every founder I speak to believes the technical part of a proposal is the part they cannot judge. So they skip to the number at the bottom, compare it against the other quote, and pick. That is exactly backwards. The number at the bottom is the least informative thing in the document.

What a proposal really tells you is how the team thinks. Have they written down what they are assuming? Have they said what is not included? Do they mention testing, deployment and handover, or does the work mysteriously end at "build"? Have they told you what happens when something takes longer than they hoped — because it will. None of that requires you to read a line of code.

This matters because software estimates are structurally unreliable — not because agencies are dishonest, but because early estimates are made when the least is known. So you are not reading a prediction; you are reading a negotiating position about a genuinely uncertain thing. A proposal that admits uncertainty is worth more than one that pretends there isn't any.

Why the number at the bottom is the least useful thing in the document

Steve McConnell's work on estimation describes what is known as the Cone of Uncertainty. An estimate made at initial concept — before anyone has designed anything, before the requirements are pinned down — can be wrong by a factor of four in either direction: a total spread of sixteen times between the lowest and highest defensible number for the same work. The cone narrows as decisions get made, but when you are reading a proposal you are standing at its widest part.

The outcome data matches. McKinsey and the University of Oxford studied more than 5,400 IT projects and found large ones ran 45% over budget on average while delivering 56% less value than predicted. Bent Flyvbjerg and Alexander Budzier examined 1,471 IT projects and found one in six became a "black swan": an average cost overrun of 200% and a schedule overrun of nearly 70%. The problem with software projects is not that they typically run a bit over. It is the fat tail.

Six sections, and only one of them is the price

A proposal worth signing has six things in it. Scope, described in outcomes rather than technology — "users can sign up, verify their email and invite two colleagues" is scope; "modern microservices architecture with a React front end" is a technology choice dressed up as scope. Assumptions: what must be true for the price to hold, such as designs arriving by a certain date. Exclusions: what is explicitly not in the price, from copywriting to data migration and post-launch support.

Then team shape and day rates — who does the work, how senior, and what they cost per day. The median UK day rate for a contract developer in the six months to August 2026 was £500, and £535 in London. An agency sits above that because it carries project management, quality assurance, holiday cover and margin, but the contractor rate is the floor. If a quote implies far below it, someone junior is doing the work or the number is not real.

Finally, a contingency line — an explicit percentage for the unknown, whose presence is a mark of maturity rather than weakness — and a delivery section covering testing, deployment and handover. Most weak proposals have scope and price, and nothing else. The missing sections are not an oversight; they are where the risk has been parked on your side of the table.

What absence tells you

Four things should make you slow down. No assumptions section at all, the most reliable signal of a team that has not thought hard. A fixed price attached to a vague scope. "We'll use the latest AI" listed as a feature rather than a method — AI belongs in the price and the timeline, so ask directly how it changes the number of days quoted. And no mention of testing, deployment or handover.

The fixed price on a fuzzy scope is the loudest warning in the document. A fixed price is only meaningful if the scope is genuinely fixed too, which requires real discovery work. Without it, one of three things is coming: expensive change requests for anything not literally written down, quality quietly compressed as the supplier's margin evaporates, or a risk premium baked into the price that you pay whether or not the risk materialises. PMI's research has found around half of projects experience scope creep, so a contract that treats change as a violation rather than an expectation will spend its life in dispute.

Four sentences that do the work

Ask these on a call rather than by email, and listen to how the answers arrive as much as what they contain. "What happens if this takes longer than you've estimated — who pays?" There is no wrong answer, but there is a wrong reaction: a good supplier has a pre-agreed mechanism, a bad one tells you it will not happen. "What is explicitly not included?" If they cannot answer immediately, every boundary will be discovered mid-project, at your expense.

"Who owns the repository, the cloud accounts and the IP the day we stop working together?" This is the one founders skip and later regret. Under UK law, when you commission someone to create a copyright work, the creator is the first legal owner unless you agree otherwise in writing — the UK Intellectual Property Office says so plainly. Not because your supplier is untrustworthy, but because investors will ask, and the moment to sort it out is now rather than during due diligence.

And: "Which part of this are you least confident about?" This is the tell. Every real project has a scariest part. A team that names it has actually thought about your project. A team that says everything is straightforward is either inexperienced or managing you.

Making incomparable quotes comparable

Two quotes are almost never quoting the same thing, which is why comparing headline prices compares nothing. Stop letting suppliers define the terms: write your own one-page scope, ask every supplier to price your list, then convert everything to a common unit — total estimated days, and the blended day rate that falls out when you divide the price by the days. You will usually find the "cheap" quote is the same day rate with a third of the days, because it silently dropped testing, project management, or the features that are genuinely hard.

Then compare the assumptions sections against each other. Where two suppliers assume different things about the same project, you have found the real uncertainty in your build.

The playbook

1. 1
   Write your own one-page scope before you read anyone's proposal.

   Ten to fifteen bullet points of what the software must do, in plain English, plus three things it explicitly must not do yet. This becomes the ruler you measure every quote against, and it stops you being anchored by whoever wrote the prettiest document.

2. 2
   Ask every supplier to add an assumptions and exclusions section.

   Say it plainly: "Before I can compare these, I need a list of what you're assuming and what's excluded." How quickly and specifically they respond tells you more about the next six months than the proposal did.

3. 3
   Convert every quote into days × blended rate.

   Ask each supplier for total estimated days and the mix of people, then check it against the £500 median UK contract day rate. It shows you whether a quote is priced by effort or by what they think you'll pay.

4. 4
   Get the ownership answer in writing before you sign anything.

   Ask for an IP assignment clause, admin ownership of the repository and cloud accounts, and a named handover deliverable at the end.

5. 5
   Put a named contingency in your own budget, not just theirs.

   Whatever the quote says, hold 20–30% back internally, and agree in advance how a change request gets raised, priced and approved. The point is not to expect failure — it's to make the conversation about overrun a process instead of an argument.

A proposal doesn't tell you whether a team can build your software. It tells you how honest they'll be with you when it turns out to be harder than they said.