Reading Between the Lines: How UK Buyers Should Scrutinise a Software Agency Proposal

Most software procurements in the UK do not collapse during delivery. They collapse at signature, when a proposal that reads convincingly but specifies very little is approved because it is the only credible option on the table, or because interrogating it feels like delaying the programme. The proposal is simultaneously a commercial document and a technical one. It ought to be readable by a finance director and defensible in front of an engineering team. When it is neither, the warning signs tend to cluster in the same five places.

1. Timelines built from phases rather than outcomes

A proposal that says discovery will take four weeks, build will take twelve and launch will follow shortly afterwards has described a schedule of activity, not a schedule of delivery. It tells the buyer what the agency intends to do, not what will exist at the end of it.

A stronger document anchors each period to something observable: a working transaction flow in a staging environment by a named date, an integration with the finance system passing a defined test set, a content migration signed off by the editorial owner. Where milestones are outcome-based, slippage becomes visible early and can be discussed with evidence rather than assertion. Where they are activity-based, slippage is discovered at the end.

Ask also how the estimate was produced. An agency that can explain its assumptions about scope, team size and dependencies is one that has thought about risk. An agency that presents a single number with no workings has usually guessed.

2. Acceptance criteria that never quite arrive

The phrase acceptance criteria appears in most proposals. Far less common is a proposal that actually contains them. If the definition of done is left to a later workshop, the buyer has signed a contract in which the standard of completion is set by the supplier, after the commercial terms are fixed.

Best practice is unglamorous. Each significant requirement should carry a testable statement of completion, agreed before work begins, with a named person on the client side responsible for confirming it. Non-functional requirements deserve the same treatment: page load budgets, uptime expectations, browser support, data retention behaviour.

A useful test in the room is to pick two requirements at random and ask what evidence would be shown to prove each was met. If the answer is vague for either, the rest of the document is likely to be equally elastic.

3. Ambiguity over intellectual property and source code

Ownership questions are frequently left to the master services agreement, and frequently left vague even there. The practical consequences are substantial: a buyer who cannot take the codebase to another supplier, or who discovers that a licence for a component has been procured in the agency's name, has lost negotiating leverage at precisely the moment it is most needed.

A well-drafted proposal states plainly that bespoke work product and its intellectual property transfer to the client on payment, that third-party and open-source components are identified with their licences, and that the client will receive the repositories, documentation, infrastructure configuration and access credentials at handover and on request.

It should also address what happens to the agency's pre-existing frameworks and tooling. Reuse is sensible. Undisclosed reuse that cannot be separated from the client's system is not.

4. Commercial models that do not match the stated scope

A fixed price attached to an undefined scope is not a guarantee; it is a change request waiting to happen. Equally, a time-and-materials arrangement presented alongside a firm launch date is an optimistic fiction.

Good proposals align the commercial model with the maturity of the requirements. Where scope is genuinely uncertain, the sensible structure is a fixed-price discovery followed by a fixed-price build against an agreed specification, or a capped time-and-materials arrangement with transparent reporting. Either way, the change control mechanism should be described before it is needed: how variations are priced, who approves them, and what the escalation route looks like when there is disagreement.

5. Thin answers on team, continuity and aftercare

Proposals often present the senior people who will attend the pitch. Fewer explain who will actually do the work, whether those individuals are employees or subcontractors, and what happens when someone leaves.

Look for named roles rather than named individuals, a stated team composition by discipline, and a realistic picture of availability. Ask what proportion of the team has worked together before. Ask what the support arrangements are after launch, what response times are offered, and whether the agency operates an on-call rota or simply an inbox.

The period after go-live is where reputations are made and where most operational cost sits. A proposal that treats it as a footnote is signalling where its priorities lie.

What a good proposal looks like

A dependable proposal is usually longer than its competitors and duller to read. It restates the problem in the buyer's language, sets out assumptions explicitly, describes the architecture at a level a technical reviewer can challenge, and lists what is out of scope with as much care as what is in. It names the risks and says who owns each one.

It also tends to include an honest account of what the agency is not good at. That is not weakness; it is the mark of an organisation that has run enough projects to know where things break.

A checklist before signature

• Are milestones expressed as deliverables and dates rather than phases?
• Does every significant requirement have a testable acceptance criterion and a named approver?
• Is intellectual property assignment stated clearly, including third-party and open-source components?
• Will the client receive repositories, documentation and credentials at handover?
• Does the commercial model match the certainty of the scope, with change control described in advance?
• Is the delivery team identified by role, composition and availability?
• Are post-launch support, response times and escalation routes specified?
• Are assumptions, exclusions and risks written down and owned?

Procurement is the cheapest point at which to fix a project. An hour spent pressing a supplier on these questions costs far less than a quarter spent renegotiating them once the build is under way.