What to actually scope in an MVP development service contract: a buyer's checklist
Most MVP contracts hide the parts that matter. Here is what to demand in writing before you sign with any MVP development service, with the line items I have watched startups get burned on.
- ↳Scope the deliverable as a running production system, not a Figma file plus a GitHub repo.
- ↳Pin the stack, the hosting, and who owns every account on day one. Vague ownership is how startups lose their codebase.
- ↳Define 'done' with a checklist of user flows that pass in production, not story points or sprint counts.
- ↳Cap the unknowns with a fixed discovery phase and a separate build SOW. One giant fixed-bid contract is a trap for both sides.
- ↳Bake in a 30-day handover with code walkthroughs and an exit clause. If the vendor flinches, walk.
I have seen the same contract three times this year. Glossy PDF, twelve pages, ends with a number like $48,000 and a timeline like “10-12 weeks.” Somewhere in the middle is the word “MVP” used six times without ever being defined. The founder signs it. Four months later they call me because the vendor disappeared with the Stripe keys and the Firebase project is in someone’s personal Gmail.
This is a checklist for not being that founder. It is also, frankly, a checklist for vendors who want to stop writing contracts that quietly screw the client. We run an MVP and agent build shop at EdsDev, and the contracts that go well are the boring, specific ones.
What a real mvp development service is actually selling you
The phrase “mvp development service” gets used for at least three different things:
- A design sprint that ends in a Figma file and a clickable prototype.
- A code-for-hire arrangement where you get a GitHub repo and good luck.
- A productionized v1 that real users can sign up for, pay for, and break.
These are not the same product. The first two cost a fraction of the third and that is fine, as long as the contract says so. The thing founders actually want when they say “build my MVP” is the third one. Make sure the SOW uses that language. “A deployed web application accessible at a production URL, with at least the following user flows working end to end against live infrastructure.” Then list the flows.
If the contract describes deliverables as “sprints” or “story points completed,” you are buying effort, not an outcome. Sometimes effort is what you want. Just know which one you signed.
The ownership clauses people forget
Every account, every key, every domain. Write it down. Who owns what on day one and who owns what at handover.
A non-exhaustive list of things that have gone sideways on projects I have inherited:
- The Vercel project was on the contractor’s personal account. Billing was attached to their card.
- The Stripe account was created with the contractor as the platform owner. Moving it required Stripe support tickets and notarized documents.
- The Apple Developer account was the contractor’s individual account, not an organization. The app could not be transferred without a D-U-N-S number the founder did not have.
- The Firebase project was inside a Google Workspace the contractor controlled.
- The domain was registered through the contractor’s Namecheap account with two-factor on their phone.
The contract should list every third-party account the project will touch (Cloudflare, Hetzner, AWS, Stripe, RevenueCat, Resend, FAL, Anthropic, OpenAI, Apple, Google Play, whatever applies) and state, for each one, who creates it, whose payment method it uses, and the exact procedure for transferring it at the end. “Vendor will create all accounts under Client’s email addresses and Client’s payment methods” is one clean way to handle it.
Code, repos, and the IP clause that actually matters
Work-for-hire language varies by jurisdiction. In Canada and the US, you generally need an explicit assignment of copyright; “work for hire” alone is not enough for software in many cases. Get a lawyer to write the IP clause. Do not copy one from a Notion template.
The practical asks:
- The repository lives in the client’s GitHub organization from commit one. Not “will be transferred at the end.” From day one.
- Every commit is pushed to that repo, not a private vendor mirror.
- Any third-party code, libraries, or prior work the vendor brings in is listed in the contract with its license. If the vendor has a “starter kit” they reuse across clients, that needs an explicit license grant or it becomes a problem the day you try to sell the company.
- AI-generated code is fine, but the contract should say the vendor is responsible for ensuring it does not contain copied proprietary code. Cursor and Claude Code are great. They also occasionally regurgitate Stack Overflow verbatim.
Defining done without using the word “done”
“Done” is the worst word in software contracts. Replace it with an acceptance checklist.
For a typical SaaS MVP, my version looks something like this:
Acceptance criteria for v1 launch:
1. A new user can sign up with email + password and Google OAuth.
2. A signed-in user can complete the core flow [describe in 1-2 sentences].
3. A user can upgrade to a paid plan via Stripe Checkout and the
subscription state is reflected in their account within 30 seconds.
4. A user can cancel and the access downgrades at period end.
5. Admin can view a list of users, their plan, and their last activity.
6. The app is deployed at https://app.client.com with TLS, runs on
[hosting], and survives a basic load test of 50 concurrent users.
7. Error tracking is wired to Sentry under the client's account.
8. A README documents local setup, environment variables, and deploy.That is what “done” means. Eight bullets. Anything else is a change order.
For custom MVP development where the surface area is fuzzier, the acceptance criteria should still be a list of user-visible behaviors, not internal architecture milestones. “The recommendation engine is implemented” is not acceptance criteria. “A user with at least 5 saved items sees a recommendations section with 3-10 results that load in under 2 seconds” is.
Split discovery from build. Always.
The single biggest improvement you can make to an MVP contract is making it two contracts.
Phase one is a paid discovery: one to three weeks, fixed price, ends in a written technical spec, a wireframe set, an account inventory, and a fixed-bid quote for phase two. The deliverable of phase one is a document, not code.
Phase two is the build, scoped against that document.
This matters because nobody can honestly fixed-bid an MVP from a two-paragraph brief. Vendors who try are either padding 40% for risk or planning to nickel-and-dime you on change orders. A real minimum viable product development services engagement should have a discovery artifact you can take to another vendor if phase two negotiations fall apart. That is the test. If the discovery output is only useful to the vendor who wrote it, it is not a spec, it is a sales document.
Payment terms that align incentives
Milestone payments tied to the acceptance checklist. Not tied to time.
A pattern that works: 20% on signing, then a payment per acceptance milestone, with the final 15-20% held until 14 days after production launch with no P1 bugs. That last holdback is the difference between a vendor who finishes and a vendor who ships you 90% and ghosts.
Avoid pure hourly on an MVP unless you have a technical co-founder reviewing timesheets. Avoid pure fixed-bid without a discovery phase. T&M with a not-to-exceed cap, against a discovery spec, is usually the honest middle.
The exit clause
Every contract should answer: what happens if we stop working together in week 6?
The answers I want to see in writing:
- Client owns all code committed to date, no holdback.
- All accounts transferred within 10 business days.
- A 2-hour handover call is included at no charge.
- Vendor will answer reasonable questions by email for 30 days at a stated rate or for free.
- No non-compete that prevents the client from hiring vendor’s employees (or a reasonable, time-limited one).
If a vendor will not put a clean exit clause in the contract, that tells you everything. The good ones know most projects end eventually and would rather you leave happy than leave angry.
A short list of red flags
- The contract does not name specific technologies. “Modern web stack” is not a stack.
- No mention of where the code is hosted during development.
- “Unlimited revisions” anywhere. This is a lie that becomes a fight.
- Payment milestones tied to calendar dates instead of deliverables.
- The vendor will not name the specific engineers who will work on the project.
- The contract is under 4 pages. There is no way to scope an MVP in 4 pages.
- The contract is over 30 pages. Someone is hiding something in there.
If you want a second set of eyes on an MVP contract before you sign it, send it our way. I will tell you what I would change, whether or not we end up doing the work.
Common questions
▸How much should an MVP cost from a development service?
For a productionized web MVP with auth, payments, and one real core feature, expect $25k-$80k USD from a competent North American shop, $10k-$35k from solid teams in India or Eastern Europe, or roughly 8-14 weeks of one senior engineer's time if you hire direct. Prices below $10k almost always mean a template with your logo on it. Prices above $100k for an MVP usually mean someone is building a v2, not a v1.
▸Should I hire an MVP development company in the USA, India, or somewhere else?
It depends on what you need to optimize. US and Canadian shops are easier for tight product collaboration, regulated industries, and timezone overlap with US customers. Indian and Eastern European shops can deliver excellent work at 30-50% of the cost, but require a clearer spec going in because async iteration is slower. For a first-time founder without a technical co-founder, the timezone and communication tax often matters more than the hourly rate.
▸What is the difference between a discovery phase and the build?
Discovery produces a written spec, wireframes, an account and infrastructure plan, and a fixed quote for the build. It usually takes 1-3 weeks. The build implements that spec. Splitting them protects both sides: you can take the discovery output to another vendor if the build quote is wrong, and the vendor is not forced to guess at scope when pricing. Any MVP development service that refuses to split them is either inexperienced or hiding risk in the price.
▸Do I really need to own the GitHub repo from day one?
Yes. The cost is zero and the downside of not doing it is losing access to your own code in a dispute. Create a GitHub organization under your company, add the vendor's engineers as collaborators with the access they need, and require all commits to land there. If a vendor pushes back, ask why. The honest reasons (they want to reuse a private starter kit) are solvable with a license clause.
▸What should I do if my current MVP contract is already vague?
Write an amendment before more money changes hands. List the acceptance criteria for launch, the accounts and their owners, the repo location, and the handover terms. Get it signed. If the vendor refuses, that is information. Pay for an independent technical review of the codebase ($1-3k buys a few hours from a senior engineer) so you know what you actually have before the relationship ends.
Related posts
How to vet MVP development companies without getting burned: 12 questions
Twelve questions I use to separate real MVP development companies from agencies that will burn six months of runway and ship a demo. Here's what to ask.
An AI lead generation agent that books meetings while you sleep
How we build AI lead generation agents that actually book meetings: the workflow, the prompts, the guardrails, and the bits that quietly break at 3am.
MVP software development when the prototype already exists
A field guide to finishing what Cursor, v0, and Claude Code started. How to take a half-working vibe-coded prototype and ship it as a real MVP without rewriting from scratch.