The Four Rows Missing From Every Proposal Scorecard

Score the proposals. The instruments already exist and some of them are good - one guide we read supplies a scope table and a one-page card scoring five dimensions from zero to ten, filled in independently by each stakeholder before anyone compares notes. Use it.

Then add the four rows it does not have: who owns the code, who holds the accounts, what happens at handover, and what happens if you leave. A proposal can win on price, scope, architecture and process and still fail all four, and those are the four that decide whether you own a system in three years or rent one.

What the published scorecards already do well

It would be dishonest to present scored comparison as an idea we are introducing. Of the two guides we opened on 24 August 2026, both had already solved the mechanical problem.

The stronger of the two gives you two instruments. The first is a scope comparison table: requirements down the side, vendors across the top, each cell marked as included, partial, or not included. That single table does most of the work of making structurally different documents comparable, because it forces every proposal onto the same list of things rather than letting each one define its own.

The second is a proposal scorecard, scoring six areas from zero to ten - scope coverage, architecture and technical quality, delivery model and risk handling, process and communication rhythm, total cost of ownership over a three-to-five-year window, and vendor fit including references. Its best feature is procedural rather than analytical: everyone scores independently before discussing, which stops the loudest opinion in the room setting the anchor.

The second guide, a UK one aimed at exactly this reader, offers an evaluation matrix across three agencies and seven dimensions - problem understanding, solution architecture, scope definition, timeline structure, pricing model, team and process, and references.

Between them that is a solid, sensible apparatus, and if you use either you will be ahead of comparing three PDFs by their totals.

The four rows nobody scores

Here is what neither of them contains.

Not underweighted - absent. The stronger guide does not address ownership or handover at all. The UK guide omits intellectual property, source-code ownership, maintenance responsibility, and post-launch handover entirely, while carrying seven dimensions about how the work will be done.

That is a strange gap, because these are the rows that survive the project. Architecture quality matters for two years. Who owns the repository matters for as long as the software runs.

Row	The question	What a good answer looks like	The red flag
Ownership	Who owns the source code, and from when?	Full assignment on final payment, stated in the proposal, with the code in a repository you administer from the first commit	”You own the software” with no mention of the repository, or ownership contingent on continued payment
Accounts	Whose name is on hosting, domains, and third-party services?	Yours, or a shared organisation you administer, listed explicitly	Silence, or “we manage all that for you” offered as a convenience
Handover	What is physically delivered, and how is it verified?	A named list - code, data export, documentation, credentials, deployment instructions - with a demonstration	”Full handover on completion” with no inventory and no verification step
Exit	What happens if we stop working together?	A stated transition period, what is provided, and at what rate	Nothing. Most proposals say nothing, which is itself the answer

Add those four rows to whichever card you are already using. That is a better move than replacing it - the existing dimensions are sound, and this is a gap in them rather than a reason to start over.

What a good answer actually sounds like

The rows above are only useful if you can tell a real answer from a comfortable one, and the difference is usually specificity rather than tone.

On ownership, a real answer names a moment and a mechanism: assignment on final payment, code in your organisation from day one. A comfortable answer names a feeling - that you will of course own everything, that they have never had a problem with this. Ask where the repository lives today, and who can add an administrator to it. Both are one-sentence questions with verifiable answers.

On accounts, a real answer is a list. A comfortable answer is a service offer. “We handle hosting” may be genuinely convenient and is also how a dependency starts; the question is not whether they manage it but whose name is on the account while they do.

On handover, a real answer is an inventory plus a demonstration. A comfortable answer is a milestone called “handover” with a date and no contents. Ask what specifically would be delivered in the week after final payment, and how you would check that it worked.

On exit, almost every proposal is silent, and silence is not sinister - it is simply that nobody asks. Asking is disproportionately informative. A supplier who has thought about it will have a straightforward answer about notice, transition support and rates. A supplier who has not will improvise, and how they improvise tells you what leaving would feel like.

None of these questions is adversarial, and asking them early tends to improve the relationship rather than strain it. We answer them unprompted, which is a position we can afford because our whole model assumes clients can leave.

Surfacing what a proposal is resting on

Neither guide gives a method for this, and it is where most of the price difference actually hides.

Every proposal rests on assumptions, and the cheapest one usually rests on the most. They are rarely stated, because stating them makes a document longer and less confident-looking. But they are recoverable, because assumptions leave traces - a proposal that says nothing about data migration has assumed there is none; one that says nothing about permissions has assumed everyone can do everything; one that says nothing about exceptions has priced the demonstration version of your workflow.

So read for absences rather than claims. Take your own list of what the work involves and mark every item each proposal does not mention. Then ask, in writing, “is this included?” for each one. The answers arrive as revised numbers, which is the point - you have converted an invisible assumption into a priced line item, and the proposals become comparable in a way no scorecard row achieves on its own.

Do this before you compare totals. A number is not comparable to another number until you know what each one assumed away.

Making two different scopes into one list

The UK guide we read advises comparing “scope-adjusted prices” and then does not say how. It is the right instruction and the missing half is the hard part, so here is the mechanic we use.

Do not start from the proposals. Start from your own list of what the work involves - the one from your brief, written before anyone quoted. If you do not have one, write it now from the workflow rather than from the proposals, because a list derived from the documents inherits their blind spots.

Put that list down the side of a page and the suppliers across the top. Then go through each proposal and mark every row as included, excluded, or unstated. Three categories, not two - the distinction between “they said no” and “they said nothing” is the entire point, because excluded is a decision and unstated is an assumption.

Two things become visible immediately. The first is that the proposals stop being documents and become coverage patterns, and coverage patterns are directly comparable in a way prose is not. The second is that the unstated column is almost never empty, and it is usually largest on the cheapest proposal.

Now convert the unstated cells into questions and send them. You are not asking for a discount or negotiating; you are asking whether a specific thing is in. The replies do three useful jobs at once: they turn assumptions into priced lines, they show you how each supplier behaves when asked a direct question, and they produce revised numbers that describe the same work for the first time.

Only then are the totals meaningful. In our experience the ranking changes often enough that comparing before this step is close to guessing - and the change is usually not that the expensive one gets cheaper, but that the cheap one turns out to have been quoting a smaller project.

One caution: resist the urge to score this table. It is a coverage map, not a quality judgement, and a supplier who excludes something deliberately and says so is behaving better than one who leaves it unstated. Weighting the rows converts a useful picture into a number that hides what it was showing you.

The rows about afterwards

Three more absences worth adding, all of which concern the period after launch, and all of which were missing from the guides we read.

Support cost structure. Not whether support is offered, but how it is priced - retainer, hourly, bundled, or included for a period then renegotiated. This is the line most likely to change the three-year total and least likely to appear in a comparison.

Lock-in. How specific is the work to this supplier? A system built on common tools with documented deployment can be picked up by anyone. One built on a proprietary framework, or deployed by a process only they know, cannot - regardless of who owns the code.

Transition. If you needed to move to another supplier in eighteen months, what would that involve? The honest answer is never “nothing,” and a supplier willing to describe the work involved is telling you something useful about how they think about the relationship.

Read price last

Compare price only after the scored rows, the four missing rows, and the surfaced assumptions are on the table, because until then the numbers do not describe the same thing.

The cheapest proposal is very often the most excluded rather than the most efficient. That is not necessarily dishonesty; a supplier quoting narrowly may simply have read the brief conservatively. But it means the gap between two numbers is frequently a gap in scope, and closing it changes both figures.

A confident single fixed price against a thin scope deserves particular attention. It is presented as reassurance and it is usually the opposite: someone has made your assumptions for you, priced their own risk into the total, and left you no visibility into either. We would rather give a range with a stated reason than a firm number we would have to defend by argument later.

Checking the references properly

Both guides list references as a dimension and neither says what to do with them, which is a shame because references are the only part of this process that tells you about delivery rather than about document-writing.

Ask for a reference whose project resembles yours in shape rather than in industry. Two businesses in the same sector can have completely different software problems, while a workflow of similar complexity in an unrelated trade is genuinely informative.

When you get the call, avoid asking whether they were happy - everyone says yes, and a supplier does not offer a reference who will say no. Ask instead:

• “What changed between the original scope and what you ended up with?” Everything changes; you are listening for how it was handled and who paid for it.
• “What did they do when something went wrong?” Not whether anything did. Something did.
• “Who has the code and the accounts now?” This is the reference-call version of the four rows, and it is the question most likely to produce a pause.
• “Would you know how to move to someone else?” A reference who cannot answer this is describing a dependency, however satisfied they sound.

Two calls are worth more than six scored dimensions, and they take less time than filling in the card.

What this comparison cannot tell you

Three limitations, stated plainly.

It cannot assess technical quality. Nothing in a comparison of documents tells you whether the code will be any good, and the only reliable signals there are references and a small paid first phase.

It cannot tell you whether you will get on with them. Delivery is a relationship conducted under pressure, and a proposal is written by whoever is best at writing proposals - not necessarily by whoever you will work with.

And it is scoped to two guides. Our claim that ownership and handover are missing describes the two we opened on 24 August 2026, in a territory holding dozens. It would be surprising if nobody had covered these rows anywhere; the point is that they are absent from mainstream comparison advice, including a UK guide written for this exact reader.

What to do before you sign

Take whichever scorecard you are using and add four rows: ownership, accounts, handover, exit. Ask each supplier the specific questions above and write their answers into the cells verbatim rather than summarising them.

Then take your list of what the work involves and mark what each proposal does not mention. Send those as written questions. Wait for the revised numbers before comparing totals.

If a supplier will not put ownership in writing, that is your answer, and it arrived cheaply.

FAQ

One proposal is half the price of the other - is that a red flag? Not by itself, but it is a question. Half the price is usually half the scope, and the difference is normally recoverable by asking what each one assumed. Compare them again after those answers arrive; the gap often closes substantially.

Can I ask a supplier to change these terms before signing? Yes, and this is the cheapest moment to do it. Repository ownership, account naming and a handover inventory cost nothing to agree at proposal stage and are expensive to retrofit once the work is underway.

What if the supplier will not put ownership in writing? Then you have learned something important for the price of one email. There are legitimate reasons for a licensing model rather than assignment, but they should be stated openly and priced accordingly - not left vague.

How many proposals should I get? Enough to see structural differences, which in practice is two or three. Beyond that you are mostly generating comparison work, and the marginal proposal rarely changes the decision.

Notes

• Live result set retrieved 2026-08-24 (en, GB proxy) via requests req_36e93256f8ac and req_5d368b4c770e, both at zero budget. Two pages opened and read in full; a third returned HTTP 404 and was not read, so nothing here draws on it. See research/live-result-set.md.
• Scored side-by-side comparison is established practice, not our contribution. This page credits the published instruments and recommends using them. What we found absent from both opened guides is ownership and handover, assumption surfacing, and the after-launch rows - and that observation is scoped to those two guides, not to the whole market.
• The four rows, the red flags and the read-price-last discipline are Garaxe’s framing, described as we genuinely use them. No client proposal is reproduced, no example is a real client document, and no outcome, win rate or success claim is made.
• One opened guide recommends a three-to-five-year total-cost-of-ownership window. That is their recommendation, cited as such, not a standard.
• No AI-assistant answer baseline was collected - the probe was unavailable on 2026-08-24 - so nothing here is a claim about what an assistant answers for this question.
• Autocomplete returned no suggestions and no People-Also-Ask questions were returned, so this page makes no claim about what buyers search for.