MVP Deep Build: Planning Is Half

Friday evening, you start a Deep Build in the Studio. Over the weekend you refine the blueprint and go over the first build. Then on Monday morning, you message five beta testers. "I built this service. Would you try making a booking?" At the end of the link is your MVP, actually working.

At that same moment, someone else is on month three of polishing a business plan. The reason something built in 3 days beats 3 months of planning is simple. What you build gets reactions, and a plan does not. Only reactions push a business forward.

This course guides you through those 3 days. Not with reckless speed, though. As the saying "planning is half" goes, you will learn to use Deep Build's planning stage properly. One example, a home-cleaning booking service, runs from beginning to end.

An MVP is not a clumsy product with few features. It is a product that does one thing with certainty. For a home-cleaning booking service, it is the single flow of "a busy dual-income couple picks a date and confirms a cleaning booking." Reviews, recurring subscriptions, points, and chat all come later.

So the first task of MVP design is not choosing what to add but deciding what to cut. Open your one-pager and ask: which flow is absolutely required to confirm this business's hypothesis? Keep only that one and move everything else to a separate note called the "version 2 list".

The Studio has two ways of building. Quick Build is the light way, where you describe and results come right out, great for sketches and comparing drafts. Deep Build plans first. The AI asks follow-up questions about your business (clarify), shows you a design document called the blueprint, gets your confirmation, and then builds.

A business MVP is built with Deep Build. The reason is the same as building a house. A shed can go up without drawings, but a house people will live in starts with the drawings. An MVP is a house real customers will move into. One direction set right at the planning stage saves ten revisions after completion.

Deep Build starts with the prompt. A beginner's prompt lists features. "Make a booking feature, a payment feature, and an admin page." A founder's prompt carries the business. Who it is for, in what moment that person uses it, what counts as success, and what the mood should be.

For the home-cleaning booking service, the prompt carries things like this. The customers are dual-income couples with no time on weekdays. They want to finish booking on their phone at night within 3 minutes. The core flow runs from picking a date to confirming the booking. They want a clean, trustworthy feel. The four boxes of your one-pager become the prompt's raw material as they are.

If you get stuck, open the Prompt helper. It refines your prompt along with industry-specific examples, and you can preview what to expect before proceeding, so you can start with confidence.

Start a Deep Build and the AI asks you questions first. Which customer comes first, whether payments go in this round, whether you need an admin screen. You answer by picking options, and you can pick several at once. These questions are not a test. They are free consulting. The AI has found the decision points you had not thought of yet, on your behalf.

Your compass for answering is the one-sentence MVP from chapter 2. Pick "include" for what that sentence needs and "skip this round" for what it does not, and the scope tightens on its own.

And it is fine to pick wrong. You can fix anything at the next stage, the blueprint, and regeneration is free. Do not be afraid. Answer with your best judgment right now.

When clarify ends, the blueprint appears. It is the design document that lays out which screens will be built, what goes on each screen, and what data moves where. At companies, this document is called a PRD, a product requirements document. You just earned one through a few exchanges of conversation.

Spend your time here. Fixing the drawings is ten times easier and cheaper than fixing finished code. Read the sentences and walk the screens in your head as the customer. If something feels off, leave feedback right on the blueprint. Once you confirm, the build begins.

One more principle to engrave before building. A product where one core feature works smoothly to the end creates trust, and a product where five features work halfway creates distrust. Customers respond not to the number of features but to the experience of a promise being kept.

In home-cleaning terms, the flow of picking a date, confirming the booking, and seeing the confirmation screen must run without snagging even once. That single smoothness creates the first impression of "this service is trustworthy", and that first impression draws serious feedback out of your beta testers.

When a booking comes in, where does that information get stored? A database, DB for short. If that sounds hard, picture a refrigerator. Customer info in this compartment, booking records in that one, a big fridge you take things out of and put things back into. The data items in your blueprint are exactly the compartment layout of this fridge.

VibeCampus's approach has one important trait. Your data connects directly to your own Supabase, not to the platform. In other words, the fridge is in your house, not someone else's. Customer information and booking records remain your asset from beginning to end.

An MVP does not need a perfect live payment system. What it needs is a place for payment. The price is visible, there is a pay button, and pressing it leads into a demo payment flow. With just this place, you can observe the most important question: "are people trying to open their wallets?"

If a beta tester sees the price tag and presses the pay button, that is a powerful signal. If everyone stops in front of the price instead, it means you should rework the price or the offer before wiring up real payments. Place first, integration later. That is the MVP order for payments.

When the build finishes, you will want to show it off immediately. Before that, run a 10-minute review routine. First, in the preview, become the customer and actually click from start to finish. Pick a date, enter details, all the way to booking confirmation. The key is to press, not read.

Next, the phone preview. Most of your customers will arrive by phone. Check both an iPhone and a Galaxy with the Studio's phone frames. Are the buttons too small, does text get cut off, are the input fields comfortable to tap?

Finally, look at the copy. Is it the customer's language or the industry's language? "Booking" beats "initiate service application process" a hundred times over.

The last gate before sending it to others: the reliability check. One button runs four stages. It extracts the claims inside your build, cross-checks the facts against Google search, actually runs it in an isolated execution environment called a sandbox, and delivers a report with suggested fixes.

For the home-cleaning booking service, it is the machine double-checking whether the service descriptions on screen are exaggerated and whether the booking flow really works to the end. Our own eyes are always generous with our own work, so this cold second look is precious.

Now, people. Five is enough. It is an old rule of thumb that most big problems reveal themselves within the first five people. Sending to five today beats spending two weeks recruiting twenty.

Who you send it to is half the game. First priority goes to the people you met during the ideas course who actually have this problem. Keep the ask short. "I built a home-cleaning booking service. Would you try it for 5 minutes and tell me where you get stuck?" Point out the one thing you want them to look at and the quality of feedback goes up.

When feedback arrives, sort it into three kinds. Blockers (cannot proceed), confusion (do not understand what this means), and requests (would be nice to have this feature). Fix in that order too. Blockers immediately, confusion next, requests go to the version 2 list. Grant every request and the MVP gets fat again.

The tool for fixing is the refine chat. It is the feature where you request changes to a finished build the way you would in a conversation. Do not copy feedback in verbatim, rephrase it as a specific instruction. And do not stress even if a part needs a big overhaul. Regeneration is free, so you can retry a fix as many times as you like.

Time to run the whole course with your own hands. Press Try it now below and the MVP prompt for the home-cleaning booking service is pre-filled in the Studio. Starting with it as is works, and swapping in your own idea works even better.

This mission threads every chapter of the course together in one run. When you finish, open the reveal for the completion checklist.

Congratulations. You now have a link, not just words. You went from someone who explains an idea to someone who shows a product. That difference is far bigger than it sounds. Investors, customers, and colleagues all react completely differently in front of a link.

The next course is "Brand: Name, Logo, Tone". Time to give your working product a face. You will pick a name, check the trademark, and dress it in a logo and colors. Keep collecting your beta testers' feedback and come on over.