Build an MVP Week by Week: 7 Steps and Your Decisions

The 7 steps and your decision at each one

For each step, here is when it happens, the decision it needs from you, and who waits if you're late. That last part is the one to watch. A studio can only move as fast as its slowest open question. Every day a question stays open is a day the work behind it waits.

• 1. Scoping call. When: before the build. Your decision: what is the one core action of the app? Who waits if you're late: nobody yet.
• 2. Fixed quote. When: before the build. Your decision: approve the scope, or cut it down. Who waits if you're late: the start date.
• 3. Design. When: during the build. Your decision: approve the main screens. Who waits if you're late: the whole build.
• 4. Build. When: during the build. Your decision: answer product questions. Who waits if you're late: the work on that feature.
• 5. Weekly testing. When: during the build. Your decision: say what's wrong while it's cheap to fix. Who waits if you're late: the next week's work.
• 6. Launch. When: after the build. Your decision: approve the release. Who waits if you're late: your launch date.
• 7. Fixes. When: after launch. Your decision: rank the bugs real users find. Who waits if you're late: your first users.

Step 1: The scoping call

This is a free 30-minute call. You explain the problem, who has it and what the user does in the app. The goal is to name the one core action your v1 is built around. Your decision: what does the user come back to do? For a booking app, it's booking. For a habit tracker, it's logging the habit. Everything else supports that action or waits for v2. Come with:

• One sentence that says who the app is for and what it does for them.
• A short must-have list. If you can't explain why a feature serves the core action, leave it off.
• Your deadline, if you have one: an investor meeting, a demo day, a pilot customer.

Step 2: The fixed quote

Next you get the scope, the price and the timeline. Our services page describes this step as: "You get a precise price and timeline. No hidden fees." Your decision: approve the scope or cut it. Read it as two lists. The first is what's in: every screen and every user action. The second is what's out. That second list protects you, because anything not written down can turn into an argument later. If you're unsure whether a feature is worth keeping, our feature cost guides explain what common features like chat, maps and payments involve.

Step 3: Design

Design is included in the price. Before screens turn into working features, you look at the main ones: onboarding, the core flow and settings. Your decision: approve the screens fast. Here is the trap to avoid. You share the screens with a group of friends, wait for everyone to answer, and come back with opinions that contradict each other. Nothing went wrong technically, but the build now starts later than it could have. A single owner sending a few specific notes avoids that. Two habits keep this step short:

• 1. One person has the final word. Feedback from a committee goes in circles. Pick one decision maker and tell everyone else to send their comments to that person.
• 2. Give feedback on tasks, not taste. "The user can't find where to book" can be fixed today. "Make it pop" can't be fixed at all.

Step 4: The build

This is the longest step, and progress is shown to you every week. In the words of our services page: "You review output, not code." You don't need to be technical. Your decision: answer product questions the day they come in. They aren't technical questions. They're business decisions only you can make. Keep a notes file for them, so when the same kind of question comes back, the answer is already there. You'll get questions like:

• "Can a user edit a booking after paying, or only cancel it?"
• "Should the free plan show a limit, or just hide the feature?"
• "What happens when a user signs up with an email that already exists?"

The other decision during the build: new ideas

You will have new ideas. Every founder does once they see the app taking shape. Write them on a v2 list instead of dropping them into the build, and bring up anything you think can't wait with the studio before acting on it. Not sure your feature list fits in around 20 days? Book a call and bring the list. We'll tell you what fits in v1 and what goes to v2.

Step 5: Weekly testing

Testing isn't a phase at the end. Progress is shown to you every week, so each weekly review is a test. Your decision: what's wrong and how much it matters. Use the app like a new user would, then send one list, sorted by importance: broken first, confusing second, cosmetic last. One clear list gets fixed faster than 20 separate messages. It also shows the studio what to fix first if time is tight. The test, in four steps:

• 1. Sign up with an email you've never used.
• 2. Complete the core action from start to finish.
• 3. Pay, if your app charges.
• 4. Log out, log back in, and check your data is still there.

Step 6: Launch

The web app goes live. For the mobile apps, you get App Store & Google Play submission support. Your decision: approve the release. One thing to plan ahead: store review is set by Apple and Google, not by the studio. If you have a pitch or a demo on a fixed date, plan it with that review in mind rather than counting on the store approval landing the day before. For more on taking an app to the stores, see our guides on building a mobile app.

Step 7: Fixes after launch

Real users find bugs that testing missed. You get 2 weeks of corrections after launch. The code is 100% yours, on your GitHub. Your decision: rank what users report. Not every complaint is a bug. "The button doesn't work" is a bug. "I wish it did X" is v2 feedback. Keep the two apart, so the fix window goes to real problems. Owning the code matters more than it seems on launch day. With the repo on your GitHub, you choose who builds v2. For what comes after your first users, see our post-launch guides.

A founder's checklist for the whole build

If you can tick these off, you remove the most common reasons a build slows down:

• Before the build: one sentence, a short must-have list, a named decision maker.
• Design: one person approves the screens, with feedback on tasks, not taste.
• During the build: answer questions the same day, keep a v2 list, test every week.
• Launch: approve the release, plan your dates around store review.
• After launch: sort bugs from wishes and keep the v2 list growing.

How long does it take to build an MVP?

With BuildMVPFast, the build takes around 20 days. The scoping call and the fixed quote come before that. Store review comes after and depends on Apple and Google. See our MVP development page for what the package includes.

How much does it cost to build an MVP with a studio?

With us, your app on web, iOS and Android is Fixed at $3,460. You get the fixed quote before any work starts, and it includes design and 2 weeks of corrections after launch.

Can I build an MVP if I'm not technical?

Yes. Progress is shown to you every week and you review output, not code. Your job is to decide what the app does, answer product questions quickly and test it like a new user would.

What slows an MVP build down the most?

Open decisions. Late feedback on design, unanswered product questions and features added mid-build cost more time than the code does. One decision maker and a v2 list fix most of it.

What do I own at the end?

The code is 100% yours, on your GitHub. You can keep building with us or hire anyone else for v2. Want to start with step 1? Book a call and we'll scope your v1 together. Your app on web, iOS and Android, Fixed at $3,460.