Uncertainty about budget does not prevent a clear brief
Start with the business problem, who experiences it and what a better working day would look like. Describe the current process and the consequence of leaving it unchanged. A useful brief separates essential outcomes from preferred features. It does not need a detailed screen design, but it must give a supplier enough context to challenge an expensive assumption.
Offer constraints and choices instead of a blank cheque
If a spending ceiling exists, share it as a planning constraint. If funding depends on evidence, explain the decision and the person who controls it. Ask for scope options with clear exclusions and recurring costs. Avoid requesting one fixed price while leaving integrations, migration and operational responsibilities undefined; the resulting proposals may be pricing different products.
A fictional approval workflow
Suppose managers approve purchases through email. The essential outcome is a visible decision history and fewer lost requests; a mobile app and predictive reporting are preferences. Ask for one proposal using an existing internal tool and another using a focused custom application. Compare permissions, data ownership, subscription costs and the effort to change the workflow later. Label all volume and savings figures as assumptions until measured.
Make the unknowns answerable before asking for a price
Organize the brief into known facts, working assumptions and decisions still needed. A known fact might be that purchasing currently uses a shared mailbox. An assumption might be that existing employee accounts can sign in to a new tool. The open decision might be whether finance needs an immediate integration or can begin with a reviewed export. Give each significant uncertainty a person who can answer it and the evidence they would need. This keeps the supplier from quietly pricing an invented version of the business.
For the approval example, request two bounded options that preserve the same essential outcome. One can configure an existing tool; the other can implement a focused application. In both, define the same ordinary request, exceptional request and decision history. Ask the proposal to state what the business must supply, what is excluded, what work is one-time and what continues after launch. This makes differences visible without pretending that every option delivers identical flexibility. Keep optional ideas in a separate list so they do not become accidental requirements simply because they appeared in a conversation.
Choose the next spending decision rather than demanding certainty about the whole future. If the unknown sign-in arrangement could materially change the solution, a limited technical assessment may be worth agreeing first. Its output should answer that question and revise the options, with a defined boundary and cost, rather than become an open-ended research exercise. When a proposal arrives, check its assumptions against the brief and ask for explanations where they differ. Do not compare the total alone. A proposal that depends on the client cleaning data, arranging access and conducting acceptance work has a different responsibility split from one that includes those tasks. Record that split before choosing an option, so a modest initial commitment does not hide an unplanned operational burden.
Questions that make proposals comparable
| Uncertainty | A useful answer in the brief or proposal |
|---|---|
| Existing employee sign-in | Name the account owner and access needed to verify compatibility; mark unverified support as an assumption. |
| First release boundaries | State which request and exception must work, plus which integrations or convenience features are deliberately excluded. |
| Recurring ownership | Identify who maintains the workflow, manages accounts and pays ongoing service costs after delivery. |
| Next funding decision | Describe the evidence required to approve further work and the person authorized to decide, rather than imply unlimited budget. |
Give the conversation a concrete starting point
Orvun Labs can use a short brief to identify the questions that materially change scope. Include a sanitized example and a named decision-maker. The first deliverable may be a scoped options note rather than an unsupported promise of a final price.
- Which outcome must be true for the investment to make sense?
- What spending or timing constraint can be shared now?
- Which systems and data sources must participate?
- What could be removed while preserving the main benefit?
