Questions to Ask Before You Pay Any MVP Developer a Deposit

Bar width above is the part of your budget that's gone before a single screen exists that you can click. That's the whole thing in one picture: a deposit buys you nothing but a promise, so the question isn't whether the quote is good — it's how little you have to risk to find out whether the promise is.

Every year, first-time founders wire €500–€15,000 up front to a freelancer or agency found on Upwork, a Facebook group, or a cold DM, and either never hear from them again or receive a half-built app six months late that nobody can maintain. This isn't a "trust your gut" problem. It's a due-diligence problem, and due diligence here takes about twenty minutes.

The questions below apply to every route — a solo freelancer, a classic agency, a no-code contractor, an AI-assisted studio like ours. The right answers don't depend on which door you picked. If you're still choosing the door, we compared them in agency vs. freelancer vs. no-code; this article is for the moment after, when you've picked someone and they've sent an invoice.

1. "What exactly will I own — and whose name is on the accounts?"

Ask this before you ask about price. The answer should be unambiguous: you own 100% of the source code, the repository, and the design files, transferred to an account you control on completion. Not a folder they'll "send over" after final payment. Not a private repo you never get invited to.

Then ask the version of the question most founders forget: who holds the accounts? The domain registrar, the hosting, the database, the email provider, the app store listings. These should be registered in your name and paid on your card, with the developer added as a collaborator — not registered under the agency's account with you as a guest. Owning the code but not the domain is a surprisingly common way to end up unable to move without permission from someone you've stopped paying.

Red flag: hedging like "we'll discuss IP after the project" or "our standard contract keeps some rights for our portfolio." A legitimate developer transfers ownership on completion, full stop. If they won't put that in writing before the deposit, they're telling you exactly what happens after it.

2. "What does 'MVP' mean in this contract — and what does 'done' mean?"

"MVP" is not a specification. It's a word two people can nod at while picturing completely different products, and that gap is where most disputes start. Before money moves, the scope should exist as a written list: the screens, the user types, the integrations, and the one core workflow a real user completes end to end.

"Done" needs the same treatment. Done as in deployed to a live URL with a working sign-up? Or done as in "the code is finished" and hosting, payments and error handling are a separate invoice? Get the exclusions in writing, not just the inclusions. The classic bait is a €4,000 quote that quietly omits hosting setup, a payment integration, and more than one round of revisions — all of which resurface as additional scope once you're already committed.

The most efficient way to ask: "What's the thing clients are most often surprised is billed separately?" Someone with nothing to hide will just tell you.

3. "Can I see the contract before I pay, not after?"

A deposit without a signed agreement is a wire transfer to a stranger. The contract — even a one-page one — should specify:

• What's being built (the scope from question 2, not "an app")
• What "done" looks like, as a checkable list
• The payment schedule, and what each payment is released against
• The IP and account transfer clause
• What happens if either side wants out, and who keeps what

If someone asks for money before you've seen paperwork, that isn't efficiency. It's the absence of a paper trail.

4. "What's the payment structure, and why is it split that way?"

This is the single biggest predictor of how a project goes. There are three patterns, and only one of them protects you:

• 100% up front. Never. You have zero leverage the moment the money clears.
• 50% up front, 50% on delivery. Common, and still risky. If the first half funds three months of silence, your only recourse is a chargeback dispute, not a partner who owes you a working app.
• Milestone-based. The industry-standard shape is a small deposit followed by staged payments, each released against something you can see running — typically 20/30/40 with a 10% retention after launch, or an even 25% per phase across scope, build, integration and handover. Nobody gets paid for work you can't click through.

A fair first deposit for a scoped MVP is 10–20% of the total quote, released only after the written scope is signed. It covers their scheduling risk — a real developer is turning down other work to hold your slot — without transferring yours.

Be suspicious of a deposit that's large in absolute terms, not just as a percentage. 20% of a €40,000 agency engagement is €8,000, which is a real amount of runway to lose. If the numbers feel out of proportion to what you're testing, the answer is usually a smaller first phase rather than a smaller percentage. And if the quote itself looks nothing like the market, our breakdown of what MVPs actually cost in 2026 is a faster sanity check than negotiating.

5. "Who, specifically, is writing the code — and can I talk to them?"

Agencies sell you the sales team; freelancers sell you themselves. Either is fine, but you need to know which one you're buying, because the gap between "the senior engineer who scoped this call" and "whoever is cheapest and available that week" is where most MVP disasters begin.

Ask it plainly: "Will the person I'm speaking to now be the one writing the code?" If not, ask to see that person's portfolio — theirs, not the agency's — and for a short call with them before you pay anything. A legitimate shop has no reason to hide the builder from the buyer.

The same question applies to AI-assisted studios, ours included, and the honest answer matters more there, not less. AI tools make an experienced developer meaningfully faster; they make an inexperienced one produce a mess faster. Ask who is reviewing what the tools generate, and what they built before the tools existed.

6. "What happens if the date slips?"

Ask for a number in weeks for a comparable project they've actually shipped, not "it depends." A realistic range for a genuine MVP — a handful of core screens, one integration, basic auth — is 4–10 weeks depending on scope and route. If someone quotes two weeks for something the market's fastest teams take two months to do, either the scope is smaller than you think or the estimate is a sales tactic.

Then ask the follow-up that actually protects you: what happens when it slips? Because it will, at least a little. You're not looking for a penalty clause — you're looking for evidence they've thought about it. Good answers sound like: you'll know within a week of us knowing; the milestone payment doesn't release until the demo does; if it slips more than two weeks you can stop and keep everything built so far. Bad answers are reassurance without a mechanism.

7. "What happens if you disappear halfway through?"

This sounds paranoid until it happens to you, and it happens constantly. Freelancers ghost, small agencies fold, contractors take a full-time job mid-project.

The insurance is simple and free: read access to the repository from the first commit, plus something running you can look at each week, even if it's ugly. If the answer is "you'll get everything when it's finished," you have no way to verify anything and no way to recover if the project vanishes with your deposit and three months of runway. Anyone unwilling to grant read access is asking for complete trust while offering none.

8. "Can I talk to your last two clients — including one whose project didn't go perfectly?"

Everyone can produce a happy client. Ask for the project that ran into trouble and how it got resolved. That answer tells you far more about how they'll handle your inevitable scope change or bug than any highlight reel.

Ask for references you can verify independently — a real company with a website, a person findable on LinkedIn — rather than a testimonial pasted into a PDF. If they can't produce a single reference willing to take a ten-minute call, treat that as the reference.

9. "What happens after launch?"

An MVP that works on demo day and breaks the week real users touch it is the failure mode nobody warns you about. Ask what's included post-launch: bug fixes for a defined window (2–4 weeks is standard), and what the hourly or retainer rate looks like after that.

Ask one more thing: will you be able to make small changes yourself? If every copy tweak requires an invoice, you're renting your own product. If the handover includes a walkthrough of how to run and deploy it, you're free. That difference compounds for years and almost never appears in a quote.

The red flags that mean walk away, full stop

Urgency deserves a special mention because it's the one that works on smart people. Manufactured deadlines exist to stop you doing exactly the checks on this page. A real developer with a full pipeline will happily tell you their next start date is in three weeks; they won't tell you the price expires tonight.

Keep the paper trail

Everything above is worth less if it lives in a phone call. Keep the record deliberately, and it costs you nothing:

• Get the answers in writing. After a call, send a short email — "confirming what we agreed" — and let them correct it. That email is now evidence.
• Pay traceably. Bank transfer or card against a proper invoice from a real business entity, never a personal wallet. Card payments carry chargeback rights that a transfer doesn't; for larger engagements, escrow through the platform you found them on is worth the fee.
• Keep the scope document versioned. When scope changes — it will — amend the document and have both sides acknowledge it, rather than letting it drift through chat messages.
• Save the invoices and the contract somewhere that isn't your inbox. Disputes are usually lost on evidence, not on merit.

What a fair deposit actually looks like

Concretely: a signed one-page scope document. A 10–20% deposit tied to that document. Repository access from the first commit. Accounts in your name. A named human who is actually writing the code. A milestone schedule where every payment follows a demo you can click through. A defined support window after launch.

That's the whole standard, and it's not demanding — it's just rarely the default, because the default is written by whoever is collecting the deposit rather than whoever is paying it. A developer worth hiring will recognise every question on this list as reasonable. The ones who bristle have told you what you needed to know, for free, before the money moved.

---