How do you turn discovery into a proposed architecture and a written proposal that survives procurement?

Design from the constraints, not from the requirements

The requirements list from discovery is the least useful input you have, because it is a statement of what people asked for and most of it is negotiable. The design is determined by the small set of things that cannot move: the identity provider the whole organisation authenticates against, the jurisdiction the data must stay in, the ERP release they will not upgrade until 2028, the four-hour Sunday change window, the fact that the team who will operate this has two engineers and neither has run Kubernetes. Write those down first, and almost every subsequent choice is either forced or clearly bounded.

This is also how you avoid the commonest technical failure in a proposal, which is designing the system you would enjoy building. A design that is correct in isolation but needs capabilities the customer's operations team does not have is not a good design; it is a future escalation with a diagram attached.

State each constraint alongside what it forces, so the reasoning is visible rather than asserted. "Because policy data cannot leave the UK, the analytics tier is deployed in the same region and the vendor's US-hosted reporting service is excluded from scope" is a sentence a sceptical reviewer can check. A diagram that silently reflects the same decision is a sentence they have to guess at.

Two options and a recommendation

Present two options, occasionally three, and always recommend one. A single option reads as take-it-or-leave-it and gives the customer nothing to negotiate except price. Five options transfer your job to the buyer, who reads that as an absence of conviction.

The options should differ along an axis the customer cares about rather than along technology. A phased build that delivers claims intake in twelve weeks and defers migration, versus a single cutover that takes seven months and costs less in total, is a real choice about risk and time. The same solution on two different clouds is not a choice, it is indecision. Then say which one you recommend and why, in terms of their stated outcome, and name what the recommendation costs them relative to the alternative — a recommendation with no acknowledged downside is not believed.

Write for the reader you will never meet

Your proposal is scored by a panel, and the people who understood you in the room are a minority of it. Assume a finance reviewer who reads the commercial section and the assumptions, a security reviewer who reads controls and data flow and nothing else, an operations manager checking whether their team can run it, and a procurement officer scoring against published criteria with a spreadsheet. Each should be able to find their section and reach a verdict without reading the rest.

Section	Who genuinely reads it	What it must contain to score
Executive summary	The decision maker, sometimes only this	Their outcome in their words, the recommendation, the price, the timeline
Understanding of requirement	Panel, checking you listened	Their process and constraints played back, including the awkward parts
Proposed solution	Technical evaluators	The design, the reasoning from constraints, what is deliberately excluded
Delivery approach and plan	Operations and programme people	Phases, gates, what the customer must do and by when
Assumptions and dependencies	Finance, legal, delivery	Each assumption with the consequence if it is false
Commercials	Finance	Price, what triggers a change, what is not included
Acceptance and governance	Legal	How "done" is decided, and by whom

The executive summary is written last and read first, and it is the only part guaranteed to be read by the person who decides. It should be legible to someone who skips the entire technical body: what they are trying to achieve, what you propose, what it costs, when it lands, and the one reason to choose you that a competitor cannot claim.

The assumptions register is the load-bearing part

Everything else in the document is a claim; the assumptions register is the boundary of the claim, and it is what protects both margin and the delivery team. Written properly, each entry names the assumption, who owns it, and what happens if it proves false. Written as a list of caveats, it protects nobody, because "we assume timely access to stakeholders" cannot be invoked as anything.

A4  The customer provides a full extract of the legacy policy table (approx. 4.2m
    rows) in the agreed format by 14 September.
    Owner: customer data team.
    If not met: migration testing slips week for week; the cutover date moves and
    the deferred effort is chargeable at the rates in Schedule 2.

A7  Existing Entra ID groups are used unchanged; no new group taxonomy is designed
    as part of this engagement.
    Owner: customer identity team.
    If not met: adds an estimated 10-15 person-days of design and remapping, priced
    as a change under section 8.

A9  Two named customer engineers are available at 0.5 FTE each from week 2 to week 14.
    Owner: customer delivery manager.
    If not met: we backfill from our side at the Schedule 2 day rate, or the plan
    extends; we will flag within five working days of the shortfall.

Three things make those entries work. Each is falsifiable on a date, so nobody argues about whether it was met. Each has a named owner on the customer side, which converts an assumption into a shared obligation. And each states a consequence in the currency of the deal — days, dates or money — so invoking it later is arithmetic rather than an argument.

What procurement and legal do to your prose

Understand the mechanical thing that happens after your document is accepted: your words are lifted into the contract. The solution section commonly becomes a schedule, the delivery plan becomes the milestone table, and your acceptance criteria become the trigger for payment. Nobody re-drafts it into legally careful language first, so every soft phrase you wrote for readability becomes a commitment interpreted against you.

That changes how you write. Avoid unquantified performance language — "high performance", "near real time", "scales as needed" — and either give a number tied to a stated condition or say nothing. Do not describe roadmap items in the present tense, and never make a dated commitment on another team's behalf without that team's written agreement. Be explicit about what is out of scope, because the exclusions list is the only thing standing between you and the belief that anything unmentioned was included. Where an SLA appears, state what it is measured on and what is excluded from measurement, since a service level without a measurement definition is a dispute waiting to be scheduled.

The other procurement reality is compliance scoring. Many public and large enterprise evaluations score against published criteria with weightings, and an answer that is brilliant but filed in the wrong section scores zero. If the RFP numbers its requirements, your response is numbered the same way, and a compliance matrix cross-referencing every requirement to a page is not bureaucracy — it is how you avoid losing points you had earned.

Making it survivable for delivery

Before it goes out, one person from the group who would deliver the work should read it and be willing to own it — not for approval theatre, but because the question you need answered is whether they would take this plan with these assumptions at this price. If the answer is no, you have found out at the only point where it is still free.

Then hand over more than the document. The delivery lead needs the constraints list, the assumptions register with owners, the questions you never got answered, the stakeholder map including who was sceptical, and the things you deliberately said no to — because somebody will raise them again in week three, and a delivery team that does not know they were excluded will simply agree to them.

Why technically correct proposals still lose

The loss report usually says price. The real cause is more often that the document did not demonstrate understanding, because panels read a proposal partly as evidence that you listened. If your understanding-of-requirement section could be sent to another customer in the same industry with three edits, it will not score, however good the architecture underneath it is.

The second cause is a mismatch between the document and the conversation. The customer remembers what you said on the call, and if the proposal quietly widens scope to look generous, or narrows it to protect margin, without either being discussed, the panel reads that as a vendor managing them. Anything that changed between discovery and the proposal should be visible and explained, including the parts where you decided their original request was the wrong thing to build.

Write the proposal knowing that legal will contractualise your prose and your delivery team will inherit your assumptions: a recommendation with an owned consequence for every dependency wins more often, and hurts far less afterwards, than a document that reads generously and commits to nothing measurable.