The Most Expensive Document You Will Never Write

Most development projects do not fail because of bad code. They fail because the conversation that preceded the code was vague, rushed, or skipped entirely. A founder sends three vendors a two-sentence Slack message — we need a new website, can you give us a quote? — and gets back three wildly different numbers. One is $4,000. One is $38,000. One asks seventeen clarifying questions. The founder picks the cheapest, and six months later the project is over budget, behind schedule, and missing half the features they assumed were included.

This is not a vendor problem. It is a brief problem. Or rather, it is the absence of a brief.

A well-written project brief does not guarantee a perfect engagement. But it does something invaluable: it forces you to articulate what you actually need before money changes hands, and it gives every vendor the same foundation to price against. The result is quotes you can genuinely compare — and a much higher chance that the number you agree to is the number you end up paying.

Here is how to write that brief. One page is enough. You do not need a forty-page RFP. You need clarity.

Why Vague Requests Produce Dishonest Quotes

Before we get into what to write down, it is worth understanding what happens on the other side of a vague request.

When a vendor receives a project inquiry with no brief, they have two choices. They can ask a dozen questions before quoting — which feels slow and risks losing the deal to someone who just threw out a number. Or they can make assumptions, pad for risk, and send a range wide enough to cover whatever the project turns out to be.

Neither of these is dishonest in intent. But the outcome is the same: you receive a number that is not grounded in your actual requirements, because your actual requirements were never defined. The vendor is not quoting your project. They are quoting a project they imagined based on incomplete information.

A one-page brief changes that dynamic entirely. It says: here is what I know, here is what I do not know, and here is what matters most. That is the soil work that makes everything after it more grounded and productive.

The Seven Sections of a One-Page Project Brief

You do not need fancy formatting. A Google Doc, a Notion page, even a well-structured email will work. What matters is that you address these seven areas honestly — including the ones where the honest answer is I am not sure yet.

1. What Does Your Business Actually Do?

One to three sentences. Not your mission statement — your operational reality. What do you sell or deliver, to whom, and how do they find you today? A vendor who understands your business model will make better architectural decisions than one who only knows you want a website or an app.

Example: We sell specialty roasting equipment to small-batch coffee producers. Most of our sales come through trade shows and referrals. Our current website is five years old and does not reflect our current product line.

2. What Is the Problem You Are Trying to Solve?

This is not the same as what you want built. A founder who says I need a new website is describing a solution. A founder who says qualified leads visit our site and leave without contacting us — our bounce rate on the product pages is 80% is describing a problem. The second version gives a vendor real information to design against.

If you are not sure what the core problem is, say that. A good vendor will help you map it during a discovery process. A vendor who skips straight to a proposal without understanding the problem is one you should be cautious about.

3. What Does Success Look Like?

Define one to three measurable outcomes that would make this project worth the investment. These do not need to be sophisticated analytics targets. They need to be specific enough that six months from now, you and your vendor can look at the same data and agree on whether the project worked.

Good examples: Increase monthly demo requests from 12 to 30. Reduce deploy time from 45 minutes to under 5. Launch a content channel that produces 8 posts per month without requiring anyone on our team to appear on camera.

Bad example: A modern, professional online presence. That is a feeling, not a metric. Feelings are valid — but they cannot anchor a quote.

4. What Exists Today?

List what you already have. Current website platform. Hosting provider. Domain registrar. Analytics tools. CRM. Email marketing system. Social accounts. Any existing brand guidelines, logos, or copy you want to keep.

This section matters more than most people realize. A project that integrates with an existing ecosystem is a fundamentally different scope than a greenfield build. If a vendor does not know about your existing systems, they will either quote too low (and discover the integration complexity later) or too high (assuming they need to build what you already have).

If you do not know the answers — if your previous developer set everything up and you are not sure what platform you are on — say that. That is useful information too. It tells the vendor that part of the engagement is an audit of what exists before anything new gets built.

5. What Are Your Constraints?

Three constraints matter most, and you should be direct about all of them.

Budget range. This is the section where most people get uncomfortable, and it is the section that does the most work. You do not need to name an exact number. But naming a range — we are thinking $8,000 to $15,000 or we have no more than $25,000 for the full engagement — immediately filters out vendors who cannot work at your scale and helps appropriate vendors design a solution that fits your reality instead of their wish list.

The fear is that naming a budget means a vendor will simply charge whatever you said. That is a real risk with the wrong vendor. But with a good one, knowing your budget lets them be honest about what is achievable within it — and what would require a phased approach. That honesty is exactly what you want.

Timeline. Is there a hard deadline? A product launch, a conference, a seasonal window? Or is this a right over fast situation where quality matters more than speed? Both are valid. But they produce very different project plans and very different quotes.

Internal capacity. Who on your team will be involved, and how much time can they realistically give? A project that requires your marketing director to review copy within 24 hours will stall if that person is also running three other initiatives. Be honest about this. Vendor timelines assume a certain client response speed. If your team is stretched thin, say so upfront — it is better to build that into the schedule than to discover it during week three.

6. What Have You Already Tried?

This is the section most briefs leave out, and it is one of the most valuable. If you have worked with a previous vendor and it did not go well, say what went wrong — not to assign blame, but to help the next vendor avoid the same failure mode. If you tried to build something in-house and hit a wall, describe where the wall was.

A vendor who understands your history can design an engagement that addresses your real concerns, not just your stated requirements. And frankly, this section tells a good vendor a lot about how you think about partnerships — which helps them decide whether the engagement is a good fit on their side, too.

7. What Do You Not Know?

This is the most important section. List the questions you cannot answer. I do not know whether we need a custom build or whether a platform like Shopify would work. I do not know whether our current hosting can handle 10x our current traffic. I am not sure if we need a mobile app or if a responsive site is enough.

These open questions are not weaknesses. They are the exact places where a vendor adds the most value. A vendor who reads this section and responds with thoughtful, specific guidance — rather than just a price — is a vendor worth talking to.

What to Do With the Brief Once You Have It

Send the same document to every vendor you are evaluating. This is critical. If you give one vendor a detailed brief and another vendor a casual phone call, you are not comparing quotes — you are comparing responses to two different prompts.

When the quotes come back, look at three things beyond the number:

• Did the vendor address your stated problem, or just your requested solution? A vendor who proposes a different approach than what you asked for — and explains why — is often the one who understood the brief most deeply.
• Did the vendor identify risks or unknowns you missed? That is a sign of experience. A quote that presents zero risks is not a confident quote. It is an unrealistic one.
• Does the quote include a discovery phase? Any project with meaningful complexity benefits from a structured discovery and architecture step before full production begins. If a vendor jumps straight from your one-page brief to a fixed-price build quote with no mention of validating assumptions, that is a flag. The foundational work — the mapping, the alignment, the honest conversation about trade-offs — is what makes the build itself go smoothly.

A Brief Is Not a Contract — It Is a Conversation Starter

The goal of this document is not to lock in every detail before you talk to anyone. It is to create a shared starting point that makes the first conversation productive instead of exploratory. You will still need discovery. You will still need to iterate. But you will be iterating from a grounded position, not from a blank page.

Think of it this way: the brief is the root system. It is not the tree. But without it, nothing above ground grows the way you need it to.

When You Are Ready to Have That Conversation

At Figtree Development, every engagement begins with discovery — mapping your goals, your current systems, and the honest constraints that shape what we build together. We do not start with a proposal. We start with understanding.

If you have written your brief and want to walk through it with someone who will tell you the truth about what it will take, book a free 20-minute discovery call. No pitch. Just a grounded conversation about what you are building and whether we are the right partner to help you build it.