How we scope an MVP in one call

Most discovery calls don't end with a scope. They end with "we'll send you a quote next week," followed by two weeks of back-and-forth emails, two more weeks of internal deliberation on our end, and a proposal that misses the actual ask.

That gap is where projects die. The longer the time between "let's talk" and "let's start," the higher the chance the founder loses momentum, talks to three other studios, or rescopes the idea into something we can't help with.

So we do it differently. One call, 60 minutes, and we walk out with the scope — or with the decision not to work together. The post-call deliverable is a one-page proposal, sent within 48 hours.

This post walks through how we run that call. If you're a founder considering an MVP build, this is what to expect. If you're a developer running your own discovery calls, treat it as a working draft of something that's saved us countless wasted hours.

Before the call

We do two things before getting on a video call:

1. A 20-minute async exchange. Two or three messages over email or LinkedIn — what they're building, who it's for, rough timing and budget. If those three things aren't somewhere in the same universe as what we do, we don't schedule the call. This filters out maybe 30% of inquiries.
2. A 10-minute background check. Their LinkedIn, the company website if it exists, the competitive landscape. We show up to the call already knowing what they probably mean when they say "like Airbnb but for X."

The call itself is 60 minutes. Never more. The constraint forces sharpness.

The five questions

The first 40 minutes are spent on five questions. They sound simple. The actual conversation rarely is.

1. Who is the user, and what are they doing right now without this product?

Not "small business owners." Not "millennials." A specific, namable person with a current workaround. Founders who can describe their user's existing behavior — they use Excel spreadsheets, they call the receptionist, they pay an intern €200/month — are founders who understand their problem. Founders who can only describe the user in demographics are not ready to build.

If we can't get to a concrete answer here in five minutes, we slow the call down and stay on this question. There's no point scoping a build for a user who doesn't exist yet.

2. What's the one flow that has to work?

Every MVP has a core flow — the single sequence of actions that, if it works perfectly, makes the product viable. For a marketplace, it's list → search → book → pay. For a SaaS tool, it's sign up → set up → produce one piece of value.

We push hard to narrow this down to one flow, one user type, one happy path. Everything else — admin panels, edge cases, secondary user types, settings screens — gets noted but explicitly cut from v1.

If a founder can't name the one flow, that's signal. Either they haven't thought it through, or they're trying to build three products in one.

3. What does "launched" actually mean?

This is where most scoping calls go wrong. "Launched" means different things to different founders:

• A demo we can show investors
• A working product real users can try (with bugs, with hand-holding)
• A polished product we can charge for
• A product that can scale to thousands of users without intervention

Each of these is a fundamentally different project. The first is 4-6 weeks. The last is 6-12 months.

We name this explicitly in the call and force a choice. The honest answer for most MVPs is the second — real but unpolished, manual onboarding, monitored closely by the founder.

4. What's the actual budget, and where does it stop?

Not "we have flexibility" or "we'll figure it out." A specific range, with a hard ceiling.

We open this conversation by sharing our own floor — "MVPs with us start at €20k, most land between €25k and €60k" — and watch the reaction.

If the budget is below our floor, the call ends here. We don't try to scope down to fit; we point them at cheaper alternatives (Bubble, Webflow, an offshore team) and end the call cleanly. This saves everyone time.

If the budget is above our floor, we get specific. What's the hard ceiling? What's the budget coming from — savings, a raised round, revenue? Where does it run out?

5. What's driving the deadline?

There's always a date, even when founders say there isn't. Investor demo, conference, regulatory window, a personal life event, a competitor about to ship. We dig until we find it.

The reason matters more than the date. A demo deadline is flexible. A regulatory deadline is not. A "before I run out of money" deadline tells us this project has a different risk profile than one with VC backing.

The tradeoff conversation

Once we have answers to the five questions, we name the constraint:

Scope, timeline, and budget. You pick two.

This sounds glib, but it's the most important conversation in the call. We make the founder choose:

• Fix scope and timeline: the budget has to flex up if we hit complexity.
• Fix scope and budget: the timeline has to be elastic — if a third-party API takes longer than expected, the date moves.
• Fix timeline and budget: scope gets cut as we go. We agree in advance which features are deletable.

Most founders want to fix all three. We don't let them. We've watched too many projects collapse under that pretense — the build either ships late, ships broken, or doesn't ship at all.

The honest answer for most MVPs is fix timeline and budget, cut scope as you go. It produces the most useful outcome: a real product shipped on time, with the lowest-priority features missing rather than the highest-priority features broken.

Red flags

There are a handful of signals that end the call early. We name them politely, but we don't ignore them:

• "We'll figure out monetization later." Acceptable for some products, but a yellow flag — if there's no revenue model, there's no business, and a working MVP doesn't fix that.
• "We need it ready by [date], but the scope is still flexible." This means scope is going to grow during the build.
• "We already had a developer do half of it." We almost never inherit half-built codebases. Either we rebuild from scratch or we decline.
• "Our cofounder is technical and will be involved." Not always a red flag, but we name it. If the technical cofounder is going to write code alongside us, the project needs a different structure than a clean handover.
• "We want to give equity instead of cash." Polite no. We work for paid clients.

If three of these come up in one call, we generally don't proceed.

What we send after

Within 48 hours of the call, we send a one-page proposal. Not a 20-page deck. One page.

It includes:

1. A two-sentence summary of what we agreed we're building
2. The one core flow in plain English (3-6 steps)
3. What's in the build — a short bulleted list, usually 5-8 items
4. What's explicitly not in the build — this is the most valuable section; it prevents scope creep later
5. Timeline and milestones — typically 3 milestones with payment tied to each
6. Price and payment terms
7. What we need from the founder — decisions, content, accounts, access

If the proposal needs more than one page, we haven't scoped tightly enough. We go back and cut.

The founder signs the proposal or asks for one round of revisions. If we're still negotiating scope after two revisions, we end the engagement before it starts — that pattern doesn't fix itself once development begins.

Why we work this way

Scoping is the most important deliverable in an MVP build. Everything that goes wrong after we start coding — scope creep, missed deadlines, unhappy clients, exhausted developers — is downstream of a fuzzy scope.

Spending 60 focused minutes upfront, with the discipline to walk away from deals that don't fit, saves us weeks of pain later. It also signals something to the founder before we ever write a line of code: this is a studio that takes the project seriously, asks hard questions, and won't tell them what they want to hear.

Most of the time, that's exactly what they were hoping to hear.

Working on an MVP? We run one of these scoping calls every week or two, and we keep the slots small.

Start a project →