The Meeting Notes That Should Exist Before a Development Quote Lands

A development quote arrives and the number looks reasonable. Everyone nods. Work begins. Then, about six weeks in, the wheels start coming off. The developers are building something that works technically but feels wrong in practice. The client wants changes. The brief was clear, so why is this happening? The answer is almost always the same: the brief was not actually clear. It described what to build without explaining the constraints around it, the people it was being built for, the things that could not move, or the questions that had not yet been answered.

Getting a quote right is not about writing a longer brief. Most briefs are already too long and say too little of substance. The gap is usually in four specific areas, and without documented thinking in each of them, no developer on earth can price a project accurately. The quote will either be too low, which causes resentment later, or padded with contingency, which makes it feel inflated before anyone has done any work. Neither outcome sets a project up well.

These four areas each deserve their own document. They are not lengthy reports. They are focused records of what is known, what is fixed, and what still needs resolving before a line of code is written. Preparing them before a quote lands changes the entire shape of the conversation that follows.

Why Quotes Go Wrong Before Work Begins

Most project briefs describe the product. They explain what it should do, sometimes how it should look, and occasionally who it is for. What they rarely capture is the context around the product: the business constraints that shape what is actually possible, the emotional reality of the people who will use it, the things that absolutely cannot change, and the open questions that will inevitably surface mid-build if nobody addresses them first.

When a developer reads a brief without that context, they are filling in gaps with their own assumptions. Those assumptions might be reasonable. They are often wrong. The developer prices for the project they think they understand, and the client signs off on a quote for the project they think they described. These are frequently two different projects, and the difference only becomes visible once work is underway.

There is also a subtler problem. A founder or product owner who has been thinking about an idea for months carries enormous amounts of implicit knowledge. They know why certain things matter, what the brand should feel like, which user frustrations the product must address, and which technical constraints they inherited from a previous build. None of that is in the brief because it lives in their head and feels obvious to them. It is not obvious to anyone else.

The four documents described here are a way of making that implicit knowledge explicit before it causes problems. They take an afternoon to produce. They save weeks of rework.

The Constraints Document

Every project operates inside constraints. Budget is one of them, but it is rarely the most important. Technical constraints, timeline pressures, regulatory requirements, existing integrations that cannot be disturbed, and brand guidelines that apply to every screen all shape what can actually be built, and all of them need to be written down before anyone starts pricing.

A constraints document is a single record of everything the project must work around. It covers the technical environment, including existing infrastructure, platforms the product must connect with, devices and browsers it must support, and any legacy code that has to be preserved. It covers the business environment, including hard deadlines, compliance requirements, accessibility standards, and any dependencies on third-party services. And it covers the design environment, including existing brand assets, design systems already in place, and any visual or tonal rules that carry over from other products.

Write the constraints document in plain language, not technical language. A developer reading it should understand every line, but so should the client. If a constraint needs a paragraph of explanation, give it one.

What makes this document genuinely useful is specificity. "Must work on mobile" is not a constraint. "Must perform well on mid-range Android devices on a 4G connection, based on the demographics of our primary user base" is a constraint. The more precise the language, the more accurately a developer can account for what the work actually involves. Vague constraints produce vague estimates, and vague estimates produce budget overruns.

The User Context Summary

A brief that describes a product without describing the people who will use it is missing its most load-bearing section. Developers make hundreds of micro-decisions during a build, and many of them relate to how a feature will feel in use: how much information to show at once, how forgiving error states should be, how quickly transitions should move. Without knowing who the product is for, those decisions get made on instinct rather than evidence.

The user context summary is not a full persona document. It does not need to be. What it needs to capture is the emotional and behavioural reality of the people who will actually use the product. That means going beyond demographics and describing the situation those people are in when they encounter the product, what they are trying to do, what they are anxious about, and what a good experience would feel like to them.

People arrive at products in an emotional state, and the design has to meet them there.

For a product aimed at people managing a stressful administrative task, that context shapes everything from the tone of error messages to the length of form fields. For a product aimed at people in a moment of spontaneous discovery, the pacing and visual energy should feel entirely different. Neither of those choices shows up in a feature list. They show up in how the product is built, and they need to be documented before the build begins.

Include at least one concrete description of the moment of use: where the user physically is, what they are doing beforehand, and what emotional state they are likely to be in. This single detail often changes how developers approach pacing, error handling, and the complexity of onboarding flows.

The Non-Negotiables List

Every project has things that are fixed and things that are flexible. The problem is that clients and developers often disagree about which is which, and nobody finds out until a decision gets made that the client wants reversed. A non-negotiables list is a short, direct record of everything that cannot change without a formal conversation. It is the most important document for preventing scope disputes.

Non-negotiables fall into a few clear categories. Some are functional: the product must do this specific thing, in this specific way, without exception. Some are brand-related: the visual identity, the tone of voice, the emotional register of the experience. Some are technical: the product must integrate with this system, run on this infrastructure, or remain consistent with this existing codebase. And some are about the user experience itself: the onboarding must complete in under three minutes, the checkout must require no more than two steps, the product must work without requiring an account at first use.

• Functional requirements that define what the product must do
• Brand and tonal rules that govern how it should feel
• Technical mandates inherited from existing systems
• User experience standards that protect the core promise of the product

What the list should not contain is everything. A non-negotiables list that runs to forty items has lost its purpose. The discipline here is in being selective. If a team genuinely cannot distinguish between what is fixed and what is flexible, that is worth resolving before any quote is requested, because it signals that the product thinking still has some way to go.

Keep the non-negotiables list to a maximum of ten items. If you find yourself adding an eleventh, review the list and ask honestly whether each item is truly fixed or whether it is a preference that could adapt if circumstances required it.

The Open Questions Register

The most dangerous words in a project brief are "TBC" and "to follow". They acknowledge uncertainty without resolving it, and they invite developers to make assumptions about things that actually matter. An open questions register does the opposite: it names every unresolved question clearly, assigns ownership to whoever is responsible for answering it, and sets a date by which the answer must exist.

Open questions fall into two broad groups. The first group contains questions that must be answered before the project can be accurately scoped. These are blockers, and a developer who encounters them during estimation has no choice but to pad their quote or exclude the relevant work entirely. Examples include decisions about third-party integrations, data handling requirements, content volume, and the scope of any personalisation features.

The second group contains questions that can be answered during the project but need a documented process for doing so. These are not blockers for estimation, but they need to be on record so that when the decision point arrives, the right person is ready to make it. If those decisions get made ad hoc during a build, they rarely get made well.

A register might look like a simple table with four columns: the question itself, the person responsible for answering it, the deadline for the answer, and the current status. That is all it needs to be. The value is not in the format. It is in the act of writing the questions down explicitly, because that process surfaces assumptions that would otherwise sit hidden inside the brief until they cause a problem.

How the Four Documents Work Together

Taken separately, each of these documents addresses one dimension of project clarity. The constraints document defines what the project must work around. The user context summary grounds every build decision in the reality of the people the product serves. The non-negotiables list protects the things that matter most from being quietly traded away under budget pressure. And the open questions register makes uncertainty visible and manageable rather than hidden and dangerous.

Together, they form a complete picture of what a project actually involves before any development work begins. A developer reading all four documents has what they need to price accurately, ask informed questions, and flag genuine risks before work starts rather than after. A client who has produced all four documents has usually, in the process of producing them, resolved several misunderstandings they did not know they had.

There is a natural order to producing them. Start with the constraints document, because it defines the edges of the space you are working in. Then write the user context summary, because it gives the product its emotional grounding. The non-negotiables list comes next, because it is easier to identify what is fixed once you know what the constraints and user needs require. The open questions register comes last, because by that point the gaps in the picture are easier to see.

The process of working through these four documents in sequence is, in itself, a form of brief-quality testing. If a team struggles to complete any one of them, that difficulty usually points to something that needs resolving before a quote is requested.

Conclusion

Development quotes are not really about money. They are about confidence: the developer's confidence that they understand what they are being asked to build, and the client's confidence that the number they sign off on reflects the real scope of the work. That confidence comes from shared understanding, and shared understanding comes from documentation that exists before the quote conversation begins.

The four documents described here are not a heavy process. A focused team can produce all four in a single working day. What they prevent is the much slower, much more expensive process of resolving misunderstandings mid-build, when both sides have emotional investment in the direction things are moving and neither wants to acknowledge that the brief was unclear to begin with.

This is not just a discipline for large or complex projects. A small product with a modest budget benefits from this kind of preparation as much as a large one, possibly more, because smaller projects have less contingency to absorb the cost of misaligned expectations. Getting the groundwork right before a quote lands is not a sign of over-caution. It is the most direct route to a project that delivers what it was actually supposed to deliver.

If you are preparing to go out to development and want to sense-check your brief before the quotes come in, let's talk about your project brief.

Frequently Asked Questions