Two readers with opposite interests
The tension in this question comes from a document serving two audiences that want incompatible things. The evaluator wants specificity, because specificity is the only proxy they have for whether you have done this before, and vague proposals lose to detailed ones almost regardless of who is right. The delivery team wants latitude, because the decisions you are being asked to fix are ones nobody can make responsibly before seeing the customer's actual data, actual integrations and actual operating constraints.
The junior resolutions both fail. Write generically and you read as though you have not thought about their problem, which loses the evaluation outright. Write a full design and you have committed your delivery team to a set of choices made from a requirements document, an hour with an architect and whatever you could infer, which they will spend the first two months either implementing against their judgement or renegotiating.
The resolution is that these are not two positions on a single dial. They are different categories of statement, and the document should treat them differently and say that it does.
Commit to the boundary, illustrate the inside
The line worth drawing is between what the customer's world depends on and what is yours to change. Anything they will build against, plan around, be audited on or pay for should be stated firmly. Anything internal to your solution, whose substitution they would never notice, should be shown as an approach rather than a specification.
That means committing to interfaces and their contracts, the integration points and protocols with their systems, the data you will hold and where it will reside, the behaviour under load and failure expressed as characteristics, the operating model, the security and compliance posture, the phases and what each one makes possible, and the commercial envelope. It means not committing to which queue technology carries an internal event, how a service is decomposed, the schema of an internal store, or which of two libraries handles a transformation.
| What goes in the proposal | How it is stated | Why |
|---|
| Integration points and contracts | Committed | Their teams plan and build against them |
| Data locations, residency and retention shape | Committed | It has regulatory consequences for them |
| Performance and availability characteristics | Committed, with the assumptions they depend on | It is what they are buying |
| Named third-party products they will licence or operate | Committed, and only where sourced | It appears in their costs and their skills plan |
| Internal decomposition and component choices | Indicative, subject to design phase | Substitutable without affecting them |
| Detailed schemas and sequence flows | Illustrative, to show the approach is real | Evidence of competence, not a commitment |
Say the classification explicitly rather than hoping it is inferred. A sentence early in the design section — that architecture presented as indicative demonstrates a viable approach and will be confirmed in the design phase, while interfaces, data handling and the qualities stated are commitments — does more protective work than any amount of caveating later. It also survives being read by a procurement lawyer, which the caveats will not.
Specificity where it is cheap
The trick that lets you win on detail without freezing anything is that most of the specificity an evaluator is looking for is not architectural. They are reading for evidence that you understand their situation, and that lives in places that cost you nothing to commit to.
Name their systems and their versions as you found them. Describe their actual data volumes and the awkward part of their current process. Say what you will do about the integration everybody knows is the difficult one. Show a phase plan with what is live at the end of each phase in their business terms. Include the migration approach and the cutover with its rollback. Name the risks, including the two they are quietly worried about, with the mitigation and the owner. All of that reads as far more specific than a component diagram, and none of it constrains how you build.
Meanwhile a proposal that presents an elaborate internal architecture and says nothing about their legacy integration is transparently a template. Evaluators see enough of these to know the difference, and the detail that impresses is the detail that could only have been written about them.
The named component that becomes a commitment
The specific failure worth naming, because it recurs and because it is unglamorous enough that people miss it, concerns products and versions written into a design. Once a named product appears in a proposed architecture, three things follow that nobody intended. Their team plans skills and licensing around it. Their security function assesses it and sometimes approves it, so changing it later reopens a review that took six weeks. And if the pricing was built on it, substituting it is a commercial conversation as well as a technical one.
None of that is a reason never to name anything. It is a reason to name only what you have sourced, priced and confirmed is supportable, and to be careful when the name arrives from the customer's side. An architect asking for their preferred component in the design is asking you to inherit a constraint; if you accept it, it belongs in the document as their requirement with its consequences stated, not silently absorbed as your recommendation.
Write the change route in at the start
If you know the design will change, the document should contain the mechanism by which it changes, and that mechanism should be cheap to use. Otherwise the first design change in month two is handled as a variation, which means a commercial negotiation about something that was always going to happen.
Two devices do most of the work. An assumption stated with a consequence — if the source data is not available in this form, this component is added and the phase moves by this much — converts a future argument into a clause both sides already agreed. And a design authority named in the proposal, with the customer's architect in it and a stated remit to confirm indicative choices without a commercial change, gives the latitude a name and a governance home. Customers accept that far more readily than they accept a caveat, because it puts them inside the decision rather than on the receiving end of it.
Where the uncertainty is genuinely large, the honest instrument is a short paid design phase with a defined output. It is a harder sell and it is the difference between a plan and a guess, and a candidate who can propose it without sounding evasive is demonstrating something an interviewer is specifically listening for.
Handover is the test of the document
The check on whether you got the level right is not whether the customer signed. It is whether a delivery architect who was not in any of the meetings can pick up the proposal and know what they must honour and what they may decide.
Which is why the two failure reports from delivery teams are so consistent. Either the document commits to internals for no reason and the team is arguing with a bid they did not write, or the commitments are absent and the team discovers in month three that an interface, an availability figure or a residency constraint was agreed verbally by somebody who has moved on. A proposal that marks its own commitments is the artefact that prevents both, and getting that right is worth more to the eventual engagement than any amount of architectural elaboration on the page.
Commit to what your customer's world touches and label the rest as indicative, then name the mechanism by which the indicative parts get confirmed. Win the detail marks on their systems, their data and their risks, which costs you nothing you will later want back.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).