From Proposal to Production
I write proposals for a living, and then I have to live with them. That second half is the part most people in my trade quietly skip, and it has taught me the most. A proposal is a hopeful artefact. It describes a system that does not exist yet, sized against untested assumptions, priced against a scope that will move, and signed by people who will not be in the room when it gets built.
The gap between what gets sold and what gets built is where projects go to suffer. I have been on both sides of it — the architect who drew the optimistic diagram in presales, and the architect who had to make that diagram real eighteen months later with a smaller budget and a constraint nobody mentioned. This article is about that arc: the stages a platform passes through from a first qualification call to a live system somebody owns, and the disciplines that stop intent from leaking out along the way.
The short version of my thesis: a proposal is a promise about a system, and the only way to keep it is to carry the reasoning forward, not just the design. The diagram travels fine. The why behind every box is what gets lost, and the why is what you need when reality pushes back.
The proposal as a hopeful artefact
A proposal is written to win. That is its job, and there is nothing dishonest about it — but it shapes the document in ways that come back to bite. It is written before discovery is complete, often before you have seen inside the customer’s environment at all. It assumes the network is healthy, the AD is clean, the change process is sane, the application vendor will cooperate, and the budget is real. Every one of those is a small loan against delivery, and delivery pays the interest.
The decisions made in presales are the ones that bite hardest, because they are made fastest and documented least. Somebody on a call says “we’ll use the existing SQL cluster” and it goes into the design as a fact. Six months later that cluster turns out to be at end of life, owned by a different team, and not licensed for the new workload. The decision was never wrong on the day — it was made with the information available, under time pressure, to keep the proposal moving. The failure is that the reasoning never travelled with it. Nobody recorded “we assumed the SQL cluster because the customer said it had headroom; this needs validating in discovery.” So the assumption hardened into a commitment without anyone choosing to commit — and a decision you cannot reconstruct the reasoning for is one you will re-litigate badly, under pressure, at the worst possible moment.
The hand-off chasm
Here is the structural problem, and it is structural, not personal. In most organisations the people who sell and scope a platform are not the people who build and operate it. Presales qualifies, designs at a high level, and writes the proposal; delivery picks it up after the contract is signed; operations inherits it after go-live. Each hand-off is a cliff edge, and context falls off every one of them.
The presales architect knows things that never make it into the document: which requirements were firm and which were the customer “thinking out loud”, why a product was chosen over the obvious alternative, what the customer is really worried about underneath the stated requirement, which sizing numbers are confident and which are guesses. That tacit knowledge is the most valuable thing in the engagement, and the standard process throws most of it away at the first hand-off.
The two dotted lines are where I have watched the most damage happen. The first, proposal to detailed design, is the sales-to-delivery chasm: the architect who understood the intent is reassigned to the next bid, and a delivery engineer inherits a document and a set of commitments without the reasoning behind either. The second, cutover to handover, is the delivery-to-operations chasm: a working system thrown over a wall to a team who were not consulted on any of the decisions they now have to live with at 2am. The dotted feedback line from Operate back to Qualify is, in most organisations, the one that does not exist at all — what operations learns never reaches the people writing the next proposal, so the same hopeful assumptions get made again. Projects do not usually fail at the build; they fail at the joins.
What actually changes at each stage
The stages look linear on the diagram. They are not. Each one is where a particular kind of reality arrives.
Qualification is where you decide whether to be here at all. I have written about this discipline in building an AI consultancy toolkit — the most valuable qualification question is often “should we walk away?” A badly qualified engagement poisons everything downstream: you spend the whole delivery fighting a misalignment you should have caught on the first call.
Discovery is where the proposal’s assumptions meet the environment, and where you find the undocumented dependency, the firewall rule nobody can explain, the “temporary” integration that has been load-bearing for four years. Everyone wants to rush it because the customer wants a number, but it is the stage that determines whether the number is real. Every hour cut from discovery is repaid with interest in the build.
High-level design and proposal is where ideal meets budget. The architecture I would draw with no constraints is never the one that gets signed — the customer has a number in their head, a renewal date driving urgency, and an incumbent system that must keep running throughout. The discipline is to record which compromises you made, so that when someone asks in eighteen months “why didn’t we just do it properly”, the answer exists.
Detailed design is where the hand-wave becomes a buildable specification and the gaps in the proposal become visible. “We’ll integrate with their identity provider” is a line in a proposal; in detailed design it becomes forty decisions about claims, conditional access, fallback authentication, and what happens when the IdP is down. This is the stage that most exposes the cost of a shallow proposal.
Build is where the constraints nobody mentioned arrive in person — the change freeze over the customer’s financial year-end, the application vendor who needs six weeks’ notice for anything, the one engineer who knows the legacy system and is on long-term sick. None were in the SoW; all are now your problem.
Test, migrate, cutover is where “it works in the lab” meets real users and real data. Migration is almost always harder than the build, because the build is greenfield and clean while migration drags a live, messy, in-use system across without dropping anything. Scope creep concentrates here, because this is where the customer finally sees the thing and realises what they really wanted.
Handover and operate is where the project ends and the system’s real life begins — and it is the stage given the least time and respect. I will come back to it, because “production” is the word everyone uses and almost nobody defines.
Why the reasoning has to travel — ADRs and traceability
The single discipline that has changed how I deliver is recording decisions as decisions, with their reasoning, in a durable place that travels across every hand-off — Architecture Decision Records. I went deep on the knowledge side of this in building knowledge instead of documents, but the delivery angle is specific: an ADR is how a decision survives the people who made it.
A design document tells you what the system is. It does not tell you why, and the why is what you need when reality pushes back. When a delivery engineer hits the SQL cluster problem from earlier, a design document says “uses existing SQL cluster” and leaves them stranded. An ADR says “we chose the existing cluster over a new instance to avoid licence cost and because the customer stated it had headroom; this assumes it is supported through 2027 and licensed for this workload; if either is false, revisit and price a dedicated instance.” Now the engineer knows what assumption broke, what the alternative was, and what it costs to change course. The decision is recoverable.
I keep ADRs as plain Markdown in the project repository, next to the code and the runbooks, version-controlled, so the decision log is part of the deliverable and not a slide deck that dies in someone’s inbox. A template I have settled on:
# ADR-014: Identity provider for the new platform
- Status: Accepted
- Date: 2026-04-18
- Deciders: K Haynes (architect), customer infra lead
- Supersedes: ADR-009
## Context
The platform needs SSO. The customer runs Entra ID for M365 but
also has an on-prem AD FS estate still serving two legacy apps.
## Decision
Use Entra ID as the sole IdP for the new platform. Do not extend
AD FS. Legacy apps stay on AD FS until their own migration.
## Consequences
- Positive: one identity plane, Conditional Access applies natively,
no AD FS lifecycle to own for the new system.
- Negative: two legacy apps remain on AD FS short-term; a second
migration is implied and must be tracked as a dependency.
- Assumption: customer's Entra P2 licensing covers all platform users.
If false, revisit — Conditional Access design depends on it.
The format is unremarkable; the discipline is stating the assumption out loud with the trigger for revisiting it, and keeping the “supersedes” line. Decisions change, and a log that only shows the current state hides the fact that you considered and rejected something for a reason that might still apply.
Underneath the ADRs sits the discipline that ties the whole arc together: traceability. Every requirement should trace to a design decision, every decision to something built, and every built thing back to the requirement that justified it. When a customer asks “why is this here?” in the operate phase, I want a thread that runs requirement to ADR to build to running config. When scope creep arrives — and it always arrives — that thread lets me say “that wasn’t in the requirements, here’s the one we agreed, let’s decide together whether to add it” instead of arguing from memory.
Repeatable patterns so every delivery isn’t from scratch
If every engagement starts from a blank page, the hand-off chasm gets wider, because there is nothing shared for context to attach to. The antidote is repeatable patterns and automation, so that most of a delivery is assembling known-good parts rather than inventing everything fresh.
This is the through-line of building repeatable customer health checks. A health check is a reusable framework that turns discovery from a bespoke investigation into a repeatable assessment — the same queries, posture checks, and prioritised report run against every tenant. It makes discovery faster and more honest, because you are measuring the environment rather than relying on what the customer tells you about it, and it makes the operate phase easier, because the same tooling that assessed the environment before the build can monitor it after.
The same logic applies to the designs themselves. I argued in modern Citrix architecture for treating Citrix designs as reference architectures rather than bespoke snowflakes, and Citrix is a good worked example because it has a small number of recurring shapes — control plane in the cloud, VDAs next to the data, MCS image pipeline, Entra ID identity. Once you have built that pattern well twice, the third delivery is assembly, not invention: the proposal references the reference architecture, the detailed design inherits its ADRs, the operate phase inherits its runbooks. That is the real argument for automation too — infrastructure as code and configuration in Git are the one form of documentation that cannot drift from reality, so the build is the system and the next engineer can reproduce it exactly.
Staying involved — not throwing it over the wall
The worst thing an architect can do is design something and disappear. I have done it early in my career, and I have inherited other people’s over-the-wall designs, and both are miserable. The design that looks elegant in a proposal often has a flaw that only shows up in the build, and if the architect is gone, nobody with the full context is there to make the call. So the delivery engineer either builds the flawed thing faithfully, or improvises a fix that quietly breaks the design’s intent — and now the running system and the design document disagree, a slow-burning disaster of its own.
I stay involved through delivery. Not hovering over every task, but present at the joins — reviewing the detailed design against the proposal’s intent, available when the build hits something the design did not anticipate, in the room for cutover, and signing off the handover personally. This is partly self-interest: if I never see my own designs reach production, I never find out which of my assumptions were wrong, and I keep making them. Watching a design behave in build and operations is the only thing that makes the next proposal less hopeful and more grounded.
It is also where the awkward conversations live, and the architect is the right person to have them. When scope creeps, somebody has to draw the line between “reasonable clarification” and “new project”. When a presales commitment turns out to be undeliverable as written, somebody has to own it rather than letting the delivery team absorb the blame for a decision they did not make. These conversations are uncomfortable because they are honest, and the architect who handled the original design has the standing to have them well. Avoiding them just defers the problem to handover, where it costs more.
What production actually means
Here is the line I care about most. “It works in the demo” is not production. A demo is a system performing under ideal conditions for a friendly audience. Production is a system that survives indifference, neglect, real users doing unexpected things, and the absence of the people who built it.
A platform is in production when it is operable — somebody who was not on the project can run it from documentation that matches reality. When it is monitored — its health is visible, alerts fire to someone who can act, and a problem is noticed before the customer reports it. When it is owned — a named team has the access, the knowledge, and the mandate to keep it alive. When it is documented — not a 200-page document nobody reads, but the runbooks, the decision log, and the diagrams that let the next person reason about it. And when it is handed over — the operations team has accepted it knowingly, not had it dropped on them.
This is exactly the operational readiness I argue is the real determinant of success in why most AI projects fail. Projects rarely fail because the technology did not work. They fail because it worked in the build and was never made operable, never properly owned, never genuinely handed over. The build is the easy 80%; operability is the hard 20% everyone underfunds, and it is the only part the customer actually experiences day to day.
A system nobody can operate is not finished. It is abandoned with extra steps.
What I have got wrong
I have made every mistake in this article, which is why I can write it. I have written confident sizing numbers that were really guesses and watched them become contractual commitments I had to defend at a capacity review that proved me optimistic. I have made a presales decision to reuse existing infrastructure to keep a price competitive, and handed the delivery team a dependency that was rotten. I learned to write the assumption down next to the decision, so the risk travels with it instead of ambushing someone later.
I have thrown a design over the wall once and told myself the documentation was good enough. It was not, because no documentation captures the dozen small judgements that did not feel worth recording at the time and turned out to be load-bearing. That is the engagement that taught me ADRs are not bureaucracy — they are the only mechanism I have found that makes a decision outlive the person who made it. And I have under-scoped handover more than once, treating it as a formality rather than a phase with its own work, when the truth is the project is not done at go-live — it is done when someone else can keep the system alive without me.
Where this goes next
The improvement I am working on is making the whole arc traceable as data rather than as prose scattered across tools. Requirements, ADRs, build artefacts, and monitoring all linked, so that the thread from “the customer asked for X” to “this running config delivers X, and here is the alert that tells us if it stops” is a query, not an archaeology project. Some of that is tooling around the same Markdown-and-Git knowledge base that runs the rest of my practice; some is discipline no tool will replace.
The bigger shift is cultural, and it is the one I push hardest in the future of technical presales: close the loop between operate and qualify. The architect who writes the proposal should hear what the operations team learned, because that is what makes the next proposal honest. Most organisations are structured to prevent exactly this — the bid team and the run team never speak. The ones who fix it write proposals grounded in what their systems actually do in production, not what the slide hoped they would do.
Closing thought
A proposal is a promise about a system that does not exist yet. Keeping that promise is not a single act of building — it is a chain of hand-offs, each one a chance for intent to leak out, and the architect’s real job is to be the thread that runs through all of them. The diagram is the easy part. Carrying the why from the first qualification call to a system somebody owns and operates without you — that is the work, and most people in my trade never see it, because they leave before the system has to survive them.
The best compliment I get is not “great proposal”. It is a customer’s operations lead, two years later, telling me the platform just quietly works and they always know why it was built the way it was. That is what production means. Everything before it is a hopeful artefact.