Most MVP horror stories don't start with a bad build. They start with a good-sounding sales call, one that skipped six questions the founder didn't know to ask. None of these are gotcha questions. A good shop has crisp answers to all of them, on the spot, without needing to "check with the team."
1. "Is this a fixed quote, or an estimate?"
These aren't the same word in different clothes. An estimate is a guess that can grow. A fixed quote is a commitment tied to a specific, written scope. Get "estimate" as the answer, and ask what happens when scope changes mid-build. Get that answer in writing, not on a call.
2. "What exactly is in scope, in writing?"
A proposal that describes your product in prose ("a platform for managing X") needs pushback until it's a specific list instead: the one core user flow, the specific integrations, what's explicitly excluded. A shop comfortable quoting off a vague brief is either very good at padding for risk or about to renegotiate with you in week three. Neither is what you want.
The difference is visible on the page. Here's the same scope of work written two ways:
VAGUE:
"We will build a contract management platform for
freelancers, including upload, review, and payment
tracking features."
SPECIFIC:
Scope: one flow — freelancer uploads a signed PDF
contract, the app extracts payment terms via OCR,
and displays them for confirmation.
In scope: PDF upload, term extraction, confirmation
screen, Stripe invoicing.
Explicitly excluded: e-signature, multi-party
contracts, non-PDF formats, team accounts.
The vague version could cost $8,000 or $38,000 depending on who's reading "review" and "tracking" into it. The specific version can only be quoted one way, because there's only one thing described. If a proposal reads like the first one, that's not a drafting problem — it's a sign nobody's actually decided what's being built yet, on either side of the table.
3. "Who is actually going to build this, and are they the person I'm talking to now?"
A lot of sales conversations are run by someone senior, who then hands the actual build to whoever's available. That's not automatically bad. You should just know it's happening. Ask directly who writes the code, whether that person stays your point of contact during the build, and what happens if they're unavailable mid-sprint.
This matters more than it sounds like it should, because the handoff is where context gets lost. The person who scoped your project understood why you cut the e-signature feature, why the payment integration needs to be Stripe Connect specifically, why "done" means one thing and not another. If that understanding doesn't travel with the handoff — if it's compressed into a ticket instead of a person — you're paying to re-explain your own product to someone new, mid-build, on the clock.
4. "What do I actually own when this is done?"
Full ownership of custom code should be the default, not an upsell. Ask specifically about any third-party tools, internal frameworks, or reusable components the shop plans to use. Those are usually fine to stay theirs, but you want to know the boundary before you pay, not after.
5. "What does 'done' look like, specifically?"
"Done" gets defined the same way scope does: specifically, in writing, tied to the one core flow working end to end. Not "when you're happy with it." A shop that can't say what done means before starting won't be able to tell you when you've actually gotten it.
6. "What happens if I want to stop after the first phase?"
A scoping or discovery phase followed by a build phase is a completely normal structure. What you need upfront is whether you own the output of phase one — a spec, a prototype, a technical plan — if you decide not to continue. A vague answer means the sales pitch is protecting itself, not you.
The pattern underneath all six
All six questions are really one question asked six ways: is this specific, or is this vague? Vagueness in a sales conversation becomes cost overruns in a build. A shop that answers all six specifically, without hedging, is one worth a deposit.