Free guide · For founders
The MVP Launch Playbook
How to scope, build and ship your first version.
For founders deciding what to build first, and whether to build it with an agency. You can use every chapter with any team, including ours.
What you'll leave with
Chapter 1
Before you build: is software the next step?
An MVP is the smallest product that answers your biggest open question. If that question is still “does anyone want this?”, software is usually the slowest and most expensive way to find out. Three cheaper tests come first. Pick one:
- A landing page with a sign-up. Describe the product and count who leaves an email.
- Do it by hand. Deliver the result manually to a few customers, and charge if you can.
- A clickable prototype. Watch five target users try it, without helping them.
Build when people have shown they want it, and the next question can only be answered by real users doing the job in real software.
When an agency is not the right call
- You have a technical co-founder who can build the first version.
- An off-the-shelf tool or template already does most of the job.
- You can't yet name the one user and the one job. Do chapter 2 first.
Chapter 2
Scope the smallest version worth building
Most first versions run late for one reason: too much went into them. Scoping is deciding what stays out. Work through these five, in this order:
- The one user. Not “small businesses”, but “the office manager at a 20-person clinic”.
- The one job. The task they would pay to have done better, in one sentence.
- The must-haves. Only what that job needs, five items or fewer. Everything else goes on a “later” list.
- The success signal. What real users do that proves it works: they come back, they invite a colleague, they pay.
- The decision point. Agreed before launch: the result that makes you continue, change course or stop.
What not to pay for in your first version
| Skip in v1 | Do this instead |
|---|---|
| A custom admin panel | Use a ready-made admin tool, such as Retool or Forest Admin, or do rare admin tasks by hand. |
| Native iOS and Android apps | Start with a web app that works well on phones, or build for one platform. |
| Splitting the app into many small services | One well-organized application. Split it later, when there is a reason. |
| A full library of custom UI components | A small set of reusable screens and components is enough for now. |
| Detailed roles and permissions | Two roles, admin and user, until customers ask for more. |
| Automating rare tasks | Do them by hand until they happen every day. |
| The app in several languages (translation) | Only if your first market needs them. |
Your MVP one-pager
Fill this in before you talk to any developer. It turns a first call from “tell us your idea” into a real conversation about scope.
MVP ONE-PAGER Product: The one user (who, in one line): The one job (the task they would pay to have done better): How they do that job today, and what it costs them: Must-haves for the first version (5 or fewer): 1. 2. 3. 4. 5. Later, not now: Success signal (what real users do that proves it works): Decision point (the result that makes us continue, change course or stop): Fixed, launch date or budget? (pick one; scope is what moves) Accounts in my name from day one: code, cloud, domain, payments, analytics
Before any work starts: open the code, cloud, domain and payment accounts in your company's name, then invite the team in. It is much harder to sort out later. The full list is in chapter 7.
Chapter 3
Discovery: see it before it is built
Changing a wireframe takes an afternoon. Changing built software takes weeks of developer time. Before any code is written, you should hold these:
- User flows for the one job, step by step
- Wireframes of the key screens
- A clickable prototype you can put in front of users
- A written scope, with what “done” means for each must-have
- A list of open questions and risks
- A first estimate, based on that scope
1. User flow
2. Wireframe
3. Clickable prototype
Put the clickable prototype in front of five people who match your one user. Watch them try the one job without help. Where they get stuck is your first round of changes, and it costs almost nothing to make.
Chapter 4
Foundations you don't skip
“Build it fast and rebuild later” is half right. Some parts can be rebuilt cheaply. Others decide whether you can grow at all, and getting them wrong is how products end up rebuilt from scratch.
| Part | Why | Treat as |
|---|---|---|
| Data model | How your information is structured and stored. Hard to change once real data is in it. Have a senior engineer outside the build team review it first. | Foundation |
| Accounts and teams | If companies sign up, not just people, build for that from the start. Engineers call this multi-tenancy. | Foundation |
| Sign-up, login and roles | Use a proven login service, such as Auth0 or Clerk, or your framework's built-in login. Never build login or password handling yourself. | Foundation |
| Payments and billing | Use your payment provider's billing features, and test sign-up, upgrade, failed card, cancel and refund. | Foundation |
| Screens and styling | Will change as you learn. Keep it simple. | Can be rebuilt |
| Admin and internal tools | Ready-made, or by hand at first. | Can be rebuilt |
| Reports and dashboards | Export to a spreadsheet until users ask for more. | Can be rebuilt |
From the first week, not “after launch”
- Automated tests on sign-up, login and payment
- Every change checked automatically before it goes live
- A private copy of the app where changes are tried before customers see them (staging)
- Error monitoring, so you hear about problems before users do
- Tracking for your success signal, so you can measure it from day one
- Short written notes on the main technical decisions
Avoid getting locked in
Pick a mainstream technology that is easy to hire for. No-code builders such as Bubble are fine for a test. Hosted back-ends such as Firebase or Supabase, which run your database and logins for you, can run a real product. Before you commit to either, ask: how would we move off it, and what would that cost? If nobody can answer, that is your answer. Either way, make sure you can export your data in a standard format.
Chapter 5
From kickoff to first release
Six stages. What matters most to you is the “You approve” line under each one: the decision that is yours to make.
- 1
Discovery
The team works through your one-pager from chapter 2 with you, and turns it into a written scope.
You approve: the written scope and its priorities.
- 2
Design
User flows, wireframes and a clickable prototype of the key screens.
You approve: the prototype, after showing it to a few real users.
- 3
Build, in short cycles
The team builds the most important features first, in cycles of one or two weeks, often called sprints. You see working software at the end of each one.
You approve: what comes next, at every demo. Swap features in and out here.
- 4
Test
The team tests the product. You try the key journeys yourself on a private copy of the app, called staging.
You approve: that each must-have works as written.
- 5
Launch
Domain, analytics, error alerts, backups and a support plan are in place before go-live.
You approve: the go-live checklist.
- 6
First weeks after launch
Fix what real users hit, watch the success signal, plan the next version.
You decide: continue, change course or stop, against your decision point.
A warning sign: months of building before a single real user has tried anything. Insist on working software you can click at every demo, not slides or status updates.
What drives the cost
Before any estimate, you can see which way yours will lean. Each of these makes a first version bigger:
- Types of user. Each one (customer, admin, partner) adds screens and permissions.
- Payments. One-off payments are simpler than subscriptions, refunds and invoices.
- Integrations. Every outside system you connect to, such as a CRM or a booking tool.
- Platforms. A web app costs less than a web app plus iOS and Android apps.
- Compliance. Health, finance or children's data bring extra rules, such as HIPAA or GDPR.
- Existing data. Moving data in from spreadsheets or an old system takes time.
Keep some budget back. Hold 20 to 30% of it for the first months after launch: fixes, small changes and hosting. Real users always find something.
Want this plan for your idea, with dates? Get a free MVP estimate: an approach, a rough timeline and a rough cost range in two working days.
Chapter 6
Working with a team in another time zone
A team abroad can work well, or leave you waiting a day for every answer. The difference is agreed up front. Ask any agency these eight questions, and get the answers in writing:
- How many working hours overlap with my time zone, and when is the daily check-in?
- Who is my named contact, and who covers when they are away?
- Who exactly writes the code, and how senior are they?
- How often will I see working software, and can I click through it myself?
- Where is the work tracked, and do I get access to it?
- How fast do you reply to a message, and to something broken?
- What happens if a developer on my project leaves?
- Can I speak to a past client?
Chapter 7
Who owns what
The mistake hardest to undo is not the code. It is the accounts: the domain registered to a freelancer, the cloud account on the agency's card. Open these in your company's name before work starts, and invite the team in:
- CodeA GitHub or GitLab organization in your company's name. The team joins as collaborators.
- Cloud hostingThe AWS, Azure or Google Cloud account, with your card on it.
- Domain and DNSRegistered to you, with you as the admin.
- App store accountsApple and Google developer accounts in your company's name.
- PaymentsThe Stripe or other payment account, in your name.
- Analytics and emailAnalytics, error monitoring and the email sending service.
- Design filesThe Figma or design files, in your workspace.
- PasswordsA shared password manager you control, not passwords in chat.
Read the contract for three things
- IP: ownership of the work should pass to you as you pay for it, not only when the final invoice is paid.
- Reused code: what code or licences the team brings from earlier projects, and on what terms you can keep using them.
- Exit: what happens to access, code and documents if either side ends the work early.
When a team hands over, you should get
- Admin access to every account above, with the team's access removed or reduced
- Passwords and keys changed after the team leaves
- Setup notes: how to run the product from scratch
- A list of every service the product uses, and what each one costs
- The technical decision notes from chapter 4
Quick answers
Questions founders ask
A fixed price suits a scope that is written down and unlikely to change. Paying by the sprint suits a first version where you expect to learn as you go. Either way, agree how changes are handled before work starts.
Yes, and you should expect to. Swap rather than add: when something new comes in, something of the same size moves to the “later” list. That keeps the launch date real.
Not to build the first version. You do need someone on your side who can own technical decisions afterwards, even an independent technical advisor for a few hours a month, which is why the decision notes, setup notes and accounts in chapters 4 and 7 matter.
Usually a web app that works well on phones: one codebase, no app store review, and changes go live the same day. Build a native app first only if the one job needs the phone itself, such as the camera, location or working offline.
About Provis
An approach, a rough timeline and a rough cost range for your scope, within two working days. Sending the one-pager from chapter 2 with your request helps.
We stay on for support and maintenance. What you build next should come from what real users do with this version.
- 1We read your ideaOur team in India (IST) reads every request.
- 2Your estimate, in two working daysAn approach, a rough timeline and a rough cost range for your scope.
- 3A call, if you want oneTo talk the estimate through.
Rather talk first? Book a 30-minute call with Vivek Sharma, CEO & Founder.
Clutch 5.0 · 12 reviews
Google 4.6 · 36 reviews
Top Rated on Upwork