MVP Brief Template: What to Bring to Your First Studio Call

Why one page beats a long spec

A studio uses your brief to answer three questions: what gets built, what it costs and when it ships. At BuildMVPFast the order is simple: Free Call, Fixed Quote, Build Sprint, You Ship. The quote is fixed before any code is written. A one-page brief helps because it makes you choose. A long spec lists everything you want. A short brief shows what matters most. That makes v1 smaller, and a smaller v1 ships sooner. If you're still working out the bigger picture of how an MVP gets made, start with our guide to building a web or mobile app. This article is only about the brief.

The 5 points of an MVP brief

You can write all of this in one evening. Each point has an example, using the same made-up app: a tool for independent personal trainers.

1. The problem in one sentence

Say who has the problem and what it costs them. If you need a paragraph, the idea isn't sharp enough yet. Keep rewriting until one sentence does the job. Here is the difference:

• Weak: "Fitness is hard to manage."
• Strong: "Independent personal trainers lose clients because they track sessions in WhatsApp and paper notes."

2. Your first user

Pick one type of user for v1. Not "gyms, trainers and members". Just "independent trainers". Every extra user type adds screens, permissions and testing. You can add gyms in v2, once trainers are using the app.

3. The core action

This is the one thing your user must be able to do on day one. For the trainer app, it's "log a session and send the client a summary". A simple test: if a feature doesn't help the user complete the core action, it probably belongs in the "later" column.

4. Your features, split into "launch" and "later"

Write down every feature you can think of. Then split them into two columns. This split is the most useful part of your brief. Bring both columns to the call. The "later" column isn't wasted. It shows where the product is going, so v1 can be built in a way that leaves room for it. Not sure where a feature belongs? Ask yourself: "Would a trainer refuse to use the app without this?" If the answer is no, it goes in "later". To see which features cost the most to build, browse our feature cost guides. Here is the split for the trainer app:

• Launch (v1): sign up and log in. Later (v2 and after): social login with five providers.
• Launch (v1): create a client profile. Later (v2 and after): gym accounts with several trainers.
• Launch (v1): log a session. Later (v2 and after): analytics dashboard.
• Launch (v1): send a summary to the client. Later (v2 and after): in-app chat.
• Launch (v1): take a payment with Stripe. Later (v2 and after): referral program.

5. Your date, and the reason behind it

A date on its own doesn't tell a studio much. The reason behind it does. Write it as one line: "Investor demo on 12 December, so the core action must work on a phone in a live meeting." If you're preparing a raise, our investor and fundraising articles cover what investors look for in an MVP. Want a second opinion on your "launch" column? Book a call and bring your table. We'll tell you straight what fits in a v1. Here is how each reason changes the scope:

• Investor demo on a fixed date. The core action must work perfectly on stage. Admin screens can wait.
• Launch before a trade show. It needs to look finished and handle sign-ups on the day.
• A competitor just launched. Ship the one thing you do differently, first.
• Paying pilot customer waiting. Payments and the features that customer asked for come first.

A one-page brief template you can copy

Copy this, fill it in, and paste it into an email or a doc. MVP BRIEF:

• Problem: (who) loses (what) because (why).
• First user: (one type of user).
• Core action: on day one, the user can (one action).
• Launch (v1): one feature per line.
• Later (v2 and after): one feature per line.
• Platforms: web / iOS / Android.
• Date: (date), because (reason).
• Optional: apps I like and why, a paper sketch, tools my users use today.

The template filled in for the trainer app

Here is the trainer example, filled in. That's the whole brief. It fits on one screen.

• Problem: independent personal trainers lose clients because they track sessions in WhatsApp and paper notes.
• First user: independent trainers.
• Core action: log a session and send the client a summary.
• Launch: sign up, client profile, log a session, send a summary, Stripe payment.
• Later: gym accounts, analytics, in-app chat, referrals.
• Platforms: iOS and Android.
• Date: before the January rush, because that's when trainers sign up new clients.

What's optional, and what you can skip

Some things help. None of them are needed to get a fixed quote. Helpful, but optional:

• Screenshots of two or three apps you like, with one line on what you like about each.
• A rough sketch on paper of the main screen.
• The tools your users use today, even if it's WhatsApp and a notebook.

What you can skip

You can leave these out of your brief:

• Finished designs. Design is included in the build.
• A tech stack choice. The studio picks it based on what you need. Ours is listed on the MVP Development page.
• A technical cofounder. Many founders start without one. We compared the options in Do You Need a CTO to Build an MVP?

After the brief: what happens next

Once the scope and the fixed quote are agreed, the build sprint begins. At BuildMVPFast, that's around 20 days for your app on the web, iOS and Android. We show you progress every week, design is included, your code is 100% yours on your GitHub, and you get 2 weeks of fixes after launch. The price is Fixed at $3,460. How each week of the build works, and what to have ready for it, is covered in a separate guide on the MVP sprint. Your brief is the part you can do tonight.

Common brief mistakes

Five mistakes that slow down the first call:

• Three user types in v1. Pick one. The others go in "later".
• A "launch" column with fifteen items. If everything is a must-have, nothing is. Aim for the few features the core action needs.
• A date with no reason. "ASAP" doesn't help anyone choose what to cut. A real event does.
• Describing the solution instead of the problem. "An app with a calendar and chat" says what you want built, not why. Start with the problem sentence.
• Waiting until the brief is perfect. A rough one-page brief on the call beats a polished one sent next month.

What is an MVP brief?

An MVP brief is a one-page summary of the app you want built: the problem, the first user, the core action, the features split into "launch" and "later", and the target date with its reason. A studio uses it to define the scope and give you a price.

How long should an MVP brief be?

One page. If it runs longer, you're probably listing v2 features as must-haves. Move them to the "later" column.

Do I need wireframes before I contact an app studio?

No. A paper sketch or screenshots of apps you like are enough. At BuildMVPFast, design is included in the build.

Can I get a fixed price from a one-page brief?

Yes. The five points tell a studio what v1 must do, which is what the price depends on. At BuildMVPFast the quote is fixed before any code is written: Fixed at $3,460.

What if I'm not sure what belongs in v1?

Bring both columns anyway. Sorting features into "launch" and "later" is exactly what the first call is for. Your one page is enough to start. Book a call: it's free, it takes 30 minutes, and we'll go through your brief with you.