Build an MVP: 7 Questions to Ask Before You Sign

The 7 questions at a glance

For each question, here is what a good answer looks like and what should worry you.

• 1. What exactly is in version one? A good answer: a written feature list, plus what was cut. A warning sign: "We'll figure it out as we go."
• 2. Is the price fixed, and what would change it? A good answer: one number agreed before the build. A warning sign: a rate per hour with no total.
• 3. What will I see each week? A good answer: a working build you can tap through. A warning sign: "You'll see it at the end."
• 4. Who designs the app? A good answer: design is part of the deal. A warning sign: "Send us your designs."
• 5. Where does the code live? A good answer: on your GitHub, yours from the start. A warning sign: kept on their account until final payment.
• 6. What happens after launch? A good answer: a set period of bug fixes. A warning sign: "Fixes are billed separately."
• 7. Can I see apps you've already shipped? A good answer: real apps you can open. A warning sign: only mockups or NDAs.

1. What exactly is in version one?

This is the question that decides your cost and your date. An MVP is the smallest version of your app that lets real users do the one thing that matters. Everything else waits. A good builder will push back on your list. If your idea is a booking app for personal trainers, version one might be sign up, pick a slot, pay, and get a reminder. Chat, reviews and a loyalty program can come after you have users. Not sure what to cut? Our MVP cost calculator helps you see which features weigh the most.

• Good answer: a written list of screens and features, and a second list of what was left out on purpose.
• Walk away if: they accept every feature you mention without asking why, or the scope is a paragraph instead of a list.

2. Is the price fixed, and what would change it?

Non-technical founders lose money in one place more than any other: an open-ended bill. If you pay by the hour, every unclear spec, every rework and every slow week lands on your invoice. Ask for one number, agreed before the build starts. Then ask the follow-up most founders forget: "What would make this number change?" The honest answer is usually "if you add features to the scope we signed." That's fair. What isn't fair is a price that moves because the builder underestimated the work.

• Good answer: a fixed price tied to the written scope from question 1.
• Walk away if: you get an estimate range, a daily rate with no total, or a "discovery phase" you must pay for before you even get a quote.

3. What will I see each week?

Many failed builds look fine until the final demo. Then the founder discovers the app does something different from what they pictured, and there's no budget left to fix it. Ask what you'll see every week. You shouldn't need to read code. You should be able to open the app on your phone or browser, tap through what was built, and give feedback while changes are still cheap.

• Good answer: a weekly look at the real, working app and a short note on what's next.
• Walk away if: progress means status emails with no build to try, or the first thing you can click is the finished product.

4. Who designs the app?

Plenty of quotes cover development only. Then you find out you need a designer too, which means a second hire, a second invoice and a handover between two people who've never met. Ask whether design is part of the deal, and how many rounds of changes you get on screens before development starts. Halfway through this list and already seeing gaps in a quote you've got? Book a call and bring it with you. We'll go through it question by question.

• Good answer: design is included and done by the same team that builds the app.
• Walk away if: they expect you to show up with finished designs, or design is an add-on with its own price.

5. Where does the code live, and when is it mine?

This one feels technical. It isn't. If the code sits on someone else's account, that person controls your product. If they disappear, you may have to start over. Ask for the repository to be created on your own GitHub account from day one, with the builder added as a collaborator. Ask for 100% ownership in the contract, in plain words. If you already have a prototype from an AI builder, this question matters even more. Our guides on turning an AI prototype into production explain what to check before you keep building on it.

• Good answer: your GitHub, your repo, full ownership in writing.
• Walk away if: code is handed over "at the end" or only after the last payment, or the app is locked inside a platform you can't export from.

6. What happens after launch?

Real users find bugs that testing missed. That's normal. What matters is who fixes them and who pays. Ask how long bug fixes are covered after launch, and what counts as a bug versus a new feature. A bug is something that doesn't work as agreed in the scope. A new feature is something that wasn't in the scope. Get that line written down.

• Good answer: a set period of fixes after launch, at no extra cost, plus a clear option if you want to keep building.
• Walk away if: support starts billing the day the app goes live, or nobody can tell you who to contact when something breaks.

7. Can I see apps you've already shipped?

Mockups are easy to make. Shipped apps are proof. Ask for real products you can open, download or visit, and ask what the builder did on each one. For more on vetting a team, see our guides on hiring an MVP agency.

• Good answer: a list of live apps, with the work they did on each.
• Walk away if: every project is "under NDA," or the portfolio is only screenshots.

How BuildMVPFast answers these 7 questions

We build MVP apps for the web, iOS and Android, delivered in about 20 days. The full list of what we build is on our services page. Here is how we'd answer each question for your MVP:

• 1. Version one: we scope your core features with you on a free 30-minute call.
• 2. Price: Fixed at $3,460. You get a fixed quote before we start, for the agreed scope.
• 3. Weekly progress: we show you progress every week.
• 4. Design: design is included.
• 5. Code: the code is 100% yours, on your GitHub.
• 6. After launch: 2 weeks of fixes after launch.
• 7. Shipped apps: see "Our Work Speaks for Itself" on our home page.

What should I prepare before I talk to someone about building an MVP?

A short description of the problem, who has it, and the one action a user must be able to do in your app. A rough feature list helps, even on paper. You don't need designs or a technical spec.

Should the MVP contract be fixed price or hourly?

For a non-technical founder, a fixed price tied to a written scope is easier to control, because you know the total before the build starts. Hourly billing can work if you can write precise specs and manage the developer closely.

How do I know if a feature belongs in my MVP?

Ask whether a user can still get the main result of your app without it. If yes, it can wait for version two. Payments, sign up and the core action usually stay. Extras like chat or badges usually go.

Can I build an MVP if I already started with an AI tool?

Yes. Keep the prototype, and ask the builder to review it before they quote. Some prototypes can be hardened. Others are faster to rebuild. Asking where the code lives (question 5) tells you a lot. Got answers to these seven questions from someone else and want to compare? Book a call and we'll give you our fixed quote for the same scope.