A founder messaged me last week, two days after our discovery call. “Hey, just checking, when can I expect the proposal?”
I’d already sent him a one-page brief. Not a proposal. He wasn’t being rude, he was just expecting one and got something different. So I called him back to explain why.
A proposal commits us to a scope, a price, and a timeline. Once it’s signed, we owe the client that work. If the scope is wrong, we either eat the cost of the gap or we have an awkward scope-change conversation in week three. Neither is good for the relationship.
A brief commits us to next steps. It says “here’s what I heard, here’s what we still need to figure out, here’s what each path costs in time.” It’s the right output when six specific decisions haven’t yet landed in the call.
This post is about what those six decisions are, what I do in 30 minutes to get them resolved, and what I do when I can’t.
What a Discovery Call Actually Produces
I run two kinds of 30-minute discovery calls.
The first kind ends with a proposal in 24-48 hours. The founder shows up prepared. They’ve thought about the problem. They have a sample of their data they can share. They have a budget range in mind. By minute 25, the six decisions have all landed in the conversation, and what’s left is for me to write down the scope, sprint plan, and number.
The second kind ends with a brief in 24-48 hours. The founder is still figuring out what they want. They’re between two product directions. Their data lives somewhere they can’t access yet. Or the success criteria genuinely needs more conversation with their team. The brief documents what we agreed, what’s open, and what each next step costs.
Neither is a failure. The mistake is when I treat the second kind like the first, and write a proposal anyway. That proposal will be wrong. The price will be off, the timeline will be optimistic, and the scope will miss the half of the project we hadn’t discussed yet.
The other way to put it: a proposal is what I send when the scoping has actually landed. A brief is what I send when it hasn’t.
The Six Decisions That Have to Land
Before I’ll write a proposal, six specific things have to be decided. Not “discussed”, decided.
1. The problem and the workaround. What problem we’re solving, and what the user does today to solve it without our product. The workaround tells me the success bar.
2. The accuracy threshold. What level of correctness makes this product usable. “It needs to feel right” is not a decision. “85% on the validation set is fine because there’s a human review layer” is a decision.
3. The fallback behavior. What the product does when the AI is wrong or low-confidence. Show the answer with a flag, route to a human, block the request, retry with a different prompt. Not pre-deciding this is what creates the worst sprint-three meetings.
4. The data state. What data exists, where it lives, what shape it’s in, and whether I’ve seen a sample. I will not estimate an AI project I haven’t seen data for. The data shape moves the timeline more than the model choice does.
5. The budget range. Not a number, a range. Whether we’re at $5K, $20K, or $80K is a different project, not a different price tag for the same project. (More on how I translate that range into a real number in our estimation formula.)
6. The sign-off chain. Who has to approve this for it to start. The technical co-founder who hasn’t been on the call. The CFO who’d see the invoice. A board approval. Knowing this in minute 25 saves a week of waiting later.
When all six have landed, I write a proposal. When two or more haven’t, I write a brief.
What 30 Minutes Looks Like When It Works
The structure I use, in approximate timing.
Minutes 0-3: prep check. I send three questions in the calendar invite when I book the call: the problem in two sentences, the budget range, and what the founder hopes to do next after the call. If the founder answers them in advance, the call moves twice as fast. If they didn’t, I take the first three minutes to ask the same questions live and write down the answers.
Minutes 3-12: problem and workaround. I ask the founder to walk me through what’s happening today, step by step. Not what they want to build, what they’re doing right now to solve the problem. This is the question that produces the most useful information in a discovery call. The workaround is concrete in a way that the future product isn’t.
I take notes on three specific things: who the user is, what the manual workaround is doing well, and where it’s failing. The product needs to be better than the workaround. I want to know what “better” means before I quote a price.
Minutes 12-22: AI-specific scoping. This is where AI projects scope differently from regular software. Three questions specific to AI:
The accuracy threshold question, framed concretely: “If the AI gets 87 out of 100 right, is that good enough to ship?” Not abstract, not philosophical. A specific number. The founder’s answer tells me the architecture, the eval setup, and whether the timeline I’m thinking about is realistic.
The fallback behavior question: “When the AI is wrong, what should the product do?” If the founder hasn’t thought about it, we walk through the options together: show with a confidence flag, route to a human, block, retry. Picking one before sprint one starts is the difference between a 6-week build and a 9-week build with a contentious sprint-3 conversation.
The data question, with a request: “Can you send me a 50-100 row sample by tomorrow?” If yes, the proposal is unblocked. If the answer is “let me check” or “we don’t have it yet” or “it’s in three different systems”, that’s a brief, not a proposal. We can’t price what we haven’t seen.
Minutes 22-28: budget and decision context. I ask for the budget range. Not the exact number, the range. “Is this a $10K project, a $30K project, or a $100K project?” Founders sometimes resist this because they’re worried about being quoted up to the budget. I tell them I’d rather quote within the budget than waste both our time on a scope they can’t afford. Most are relieved when I ask directly.
For more on this, read our guide on Day 1 Discovery. I also ask about sign-off: who else has to approve this. The names matter, not just the titles. If the technical co-founder hasn’t been on this call, I want to know if they’re going to push back on the architecture, want a different language stack, or have opinions about which models to use. Better to know now than in week one.
Minutes 28-30: alignment and next steps. I summarize what I heard, including any of the six decisions that haven’t landed yet. I name them explicitly: “We don’t have the data sample yet, and the accuracy threshold needs another conversation with your compliance person.” If the founder agrees on the gaps, we’re aligned. The brief or proposal goes out the next day, and we both know which one it is.
This timing isn’t a script. The conversation takes its own shape. But the structure means I’m rarely surprised at minute 25 by something I should have asked at minute 5.
When 30 Minutes Isn’t Enough
About 30% of my discovery calls don’t fit in 30 minutes, and I want to be honest about why.
The most common reason: the founder is genuinely still figuring out what they want. They have two product directions, and the call is partly them thinking through which one to pursue. That’s a useful conversation, but it’s not a discovery call for a specific project. It’s a strategy conversation.
When this happens, I notice it around minute 15. The founder is jumping between use cases. Each one is exciting. Each one is “what if we also did this.” I have a choice: keep the call structured (which makes the founder feel hurried) or let it be a thinking conversation (which means we don’t get to the six decisions).
What I do: I tell the founder we’re in two-conversation territory. We can use the rest of the call to think through the direction, and I’ll come back with a brief outlining the two paths and what each one looks like to scope. Or we can pause now and book a second call once the direction is clearer. Most founders pick the second path once I name the trade-off.
The other reason 30 minutes isn’t enough: integrations. If the project touches three or more systems (a CRM, a call recording platform, an analytics dashboard, a payment processor), 30 minutes can’t cover the integration scope properly. I can produce a brief that names the integration questions. I can’t produce a proposal until those questions have answers, which usually takes a follow-up call with whoever owns each system.
There’s a third reason that’s harder to name. Some founders need the discovery call to feel like a sales conversation in order to proceed. They want a proposal even when the scope isn’t ready, because a proposal feels like progress. The brief feels like indecision. When I sense this, I say it directly: “The most useful thing I can give you is a brief that’s right rather than a proposal that’s wrong. Once these three things land, the proposal follows in 48 hours.” Most founders accept this when I explain why. The ones who push hard for a proposal anyway are usually the same ones who become difficult clients in week three.
The Brief vs. The Proposal: What’s In Each
Both documents are short. The difference is what they commit to.
The brief (1 page) contains:
- The problem in your words. One paragraph. If I’ve understood it wrong, you catch it here.
- What we agreed on. Specifically: which decisions have landed.
- What’s open. Specifically: which decisions haven’t landed yet. Each one with a resolution path: “Send 50-100 row data sample by EOD Friday”, “Confirm accuracy threshold with compliance team by next Wednesday.”
- A timeline range, with three numbers. Best case, realistic, push scenario. One sentence on what determines each.
- Next steps. Who does what, by when.
The proposal (2 pages) contains everything in the brief, plus:
- A specific scope for sprint 1 and sprint 2 (or sprint 1 and milestone 2 for shorter engagements).
- A specific price tied to that scope.
- A specific start date.
- A specific deliverable per sprint, with the demo cadence.
- A change-management clause: how scope changes get handled mid-project.
The proposal is signable. Once you sign, we owe you that scope at that price by that date. The brief isn’t signable. It’s a shared understanding document.
What Founders Underestimate About Pre-Proposal Work
The most common thing founders are surprised by: how much pre-proposal work they own.
When I send a brief that says “send a data sample by Friday”, the brief is not the project starting. It’s the proposal getting unblocked. The founder thinks the ball is in our court because we’ve been driving the conversation. But the proposal can’t move forward until the data sample arrives, the accuracy threshold gets confirmed, or the technical co-founder reviews the architecture direction.
I name this explicitly in the brief. “These three open items are blocking the proposal. Here’s what each one needs from your side, and what I expect to do with it once I have it.” Founders who read the brief carefully and act on the open items get a proposal in 3-4 days. Founders who treat the brief as our document and wait for us to send the proposal next can lose a week of calendar time before we re-sync.
This isn’t a process problem. It’s a clarity problem. If the brief says “open” but doesn’t say “open and waiting for you”, the founder doesn’t know they’re the bottleneck. I learned to be explicit about this after losing two weeks on a project that should have moved faster.
Teresa Torres’ continuous discovery work makes the point that discovery isn’t a phase you complete before building, it’s a habit. The 30-minute call is the start of that habit, not the end of it. The brief documents where the habit is right now, and what the next move is.
The other framing I keep coming back to is the jobs-to-be-done framework: what is the user hiring this product to do? When the discovery call is going well, the answer to that question is concrete by minute 20. When it isn’t, the brief names the question and the conversation continues. Either way, I’d rather get it right than get it fast.
The Question I Ask Myself After Every Call
After every discovery call, I ask: did the six decisions land?
If yes, I write the proposal. If no, I write the brief. The honest answer is what produces good projects. The dishonest answer (writing a proposal when the decisions haven’t landed) produces scope-creep meetings.
When I started doing this work, I was uncomfortable sending briefs. I worried it looked like indecision, or like we couldn’t quote AI projects firmly. I thought founders wanted proposals and would judge me for sending anything else. What I learned over time: the founders who appreciate the brief are the ones who go on to be the best clients. They have the same respect for scope and the same discomfort with under-defined commitments that I do.
A proposal is something we both have to live with for the next 8 weeks. A brief is a way to make sure the proposal we eventually sign is the one that’s actually right.
If you’re scoping an AI project and you’ve gotten quotes from agencies that arrived suspiciously fast, ask yourself which of the six decisions actually landed in the discovery call. If the answer is “we discussed them”, that’s not the same as “they’re decided.” The proposal that follows will discover the gap during sprint three. Better to have a brief now than the wrong proposal later.
FAQ
How long does it take to get a proposal after a discovery call?
If the six decisions have landed in the call, 24-48 hours. If they haven’t, you’ll get a brief in the same window with a list of what’s still open. Once those open items resolve (typically a data sample, an accuracy threshold confirmation, or a technical co-founder review), the proposal follows in another 2-3 days. Most projects that end up in proposal land within a week of the discovery call.
Why don’t you just give me a number on the call?
A number on the call is a guess, not an estimate. AI projects have specific variables (data state, accuracy threshold, fallback behavior, integration scope) that move the price by 30-60%. Quoting before those land means I’m either wrong on the high side (and you walk away) or wrong on the low side (and we have a difficult sprint-three conversation about scope). Both are worse than a brief that gets to a real number 3-5 days later.
What’s the difference between a brief and a proposal?
A brief is a shared understanding document. It captures what we agreed, what’s open, and what each open item needs to resolve. A proposal commits us to a specific scope, price, and timeline once you sign. The brief is what I send when scoping isn’t fully landed; the proposal is what I send when it is.
Should I prepare anything before a discovery call?
Three things: a two-sentence description of the problem, a budget range (not a number, a range), and a 50-100 row data sample if your project relies on existing data. If you have these, the call can produce a proposal directly. If you don’t, the call will produce a brief, which is fine, just adds 3-5 days to the proposal timeline.
What happens if my project doesn’t fit your scope?
I’ll tell you on the call. Some projects are outside what we build well, and saying so is more useful than writing a proposal we can’t deliver against. If the fit isn’t there, I’ll usually point you to a team that does this kind of work better than we do. The 30-minute call is partly a fit assessment, not just a scoping exercise.
Have an AI project you’re scoping and you’d rather get a brief that’s right than a proposal that’s wrong? Book a 30-minute call. I’ll walk you through the six decisions and tell you honestly whether the next document is a proposal or a brief.
