Can you really build a mobile MVP in 24 hours?

You can build a testable one. With an AI app builder the first working build takes minutes, so most of the 24 hours goes to editing, running it on a real phone, and watching five people use it. What you cannot do in a day is build a finished product, and you should not try: the point of the MVP is to learn whether the core action is worth building properly.

How many screens should a 24-hour MVP have?

Four is a good target and five is the ceiling. Every prompt in this pack is four screens: the core action, the place its results show up, one input form, and one supporting view. Each extra screen adds edits and more things for testers to get lost in, without testing the hypothesis any better.

Do I need a backend or user accounts for an MVP?

Usually not. On-device storage or mock data is enough to learn whether people complete the core action. Add a real database only when the hypothesis needs data to move between people, such as a marketplace request reaching a provider. Add sign-in only when identity is the thing you are testing.

Can I build these prompts on the ShipNative free plan?

The free plan caps each build at five screens, and every prompt here is four, so the first build fits. Free credits are limited and reset weekly, so batch your follow-up edits into a few well-written prompts instead of many one-word tweaks.

What should I do when the 24 hours are up?

Make one of three calls based on the success metric you wrote in hour zero. Keep going if most testers finished the core action without help. Change the core action if they finished it but did not care. Stop if they could not find or understand it after two rounds of fixes. Then write down what you learned before you touch the code again.

MVP in 24 Hours: 8 Copy-Paste AI Prompts + Hour-by-Hour Plan

What a good MVP prompt contains

Every prompt in this pack follows the same six-part shape. When you adapt one to your idea, keep all six parts. Leaving any of them out is how a first build drifts.

Name and phase.“Build phase 1 of…” tells the builder this is a deliberately small first version.
Navigation model.Bottom tabs or a stack, named explicitly. This one line decides the app’s structure more than any other.
Each screen, with its contents and its one main action. Say what a tap does, not only what is visible.
Data. How much seed data, how realistic, and where it lives (on-device or mock).
Look.Light or dark, one accent color, one typographic trait. That’s enough; more design direction mostly adds noise.
Out of scope. The line most people skip, and the one that keeps the build to four screens.

The 24-hour plan

The clock runs from idea to a decision, not from idea to App Store. Building takes about two of the 24 hours. The rest goes to editing, testing on a real phone, and watching people use it.

Hour 0–1

Write the hypothesis and the cut list

One sentence in the form “[who] will [core action] because [reason]”, one number that counts as success (for example “4 of 5 testers finish without help”), and a list of everything you are not building. Do this on paper before you open any tool.

Hour 1–2

Generate the first build

Paste the closest prompt from the pack below and swap in your nouns. Read the plan the builder proposes before approving it. If the plan has more screens than your prompt, say so and ask it to drop them. Fixing scope in a plan is cheaper than deleting a screen later.

Hour 2–5

Edit the core action until it is obvious

Use the follow-up prompts, one change per prompt. Work only on the path a tester takes to finish the core action. Visual polish on screens outside that path is procrastination.

Hour 5–6

Run it on your own phone

Open Run on Phone and scan the QR code: with the Camera app on iPhone, or from inside Expo Go on Android. Tap targets, keyboard overlap, and text size look different on a real device than in a browser preview. Fix anything that makes the core action awkward with one hand.

Hour 6–8

Add real data only if the hypothesis needs it

If data has to move between people, connect Supabase from the Supabase tab and ask for the specific tables. Otherwise skip this block entirely and keep mock data.

Hour 8–20

Put it in front of five people

Hand each person the phone with a one-line situation and a goal, then stay quiet. Write down where they hesitate, what they tap that is not a button, and whether they finish. Sleep somewhere in this block.

Hour 20–24

Fix confusion, then decide

Fix only the moments where two or more testers got stuck. Ignore feature requests. Compare the result to the number you wrote in hour zero and make the keep, change, or stop call.

8 copy-paste MVP prompts

Each prompt tests one hypothesis with four screens. Swap the app name, nouns, and seed data for your own, and keep the structure. They are written for ShipNative, which builds React Native apps with Expo, but the shape works in any AI app builder.

Habit tracker

Hypothesis: People keep a habit longer when the streak is the first thing they see.

Build phase 1 of a habit tracker called Streakly. Navigation: bottom tabs for Today, Stats, and Settings. Today lists up to 3 habits; each row shows the habit name, a row of 7 dots for the last week, and a large check button on the right. Tapping check logs today and animates the streak number. An “Add habit” sheet takes a name, an emoji, and a schedule (daily or weekdays). Stats shows current streak, best streak, and 30-day completion rate per habit. Settings has a reminder-time picker (UI only) and a reset button with a confirmation. Store everything on the device. Light theme, one green accent, large rounded numbers. Out of scope: accounts, sharing, real notifications.

Community wins board (social)

Hypothesis: Members will post small wins if posting takes under ten seconds.

Build phase 1 of a community app called Wins. Navigation: bottom tabs for Feed and Profile, plus a floating “Post a win” button. Feed shows cards with avatar, name, time ago, the win text, and a single “Nice” reaction with a count; tapping it toggles and bumps the count. The post screen has one text field with a 280-character counter and a Post button that returns to the feed with the new card on top. Profile shows the user’s own wins and a total count. Seed the feed with 15 realistic wins from different people. Dark theme, warm yellow accent. Out of scope: comments, follows, sign-in, moderation.

Local services marketplace

Hypothesis: Pet owners will request a quote in-app instead of texting a walker.

Build phase 1 of a dog-walking marketplace called WalkNearby. Navigation: bottom tabs for Browse and Requests. Browse lists 12 walkers as cards with photo placeholder, name, neighborhood, star rating, price per 30 minutes, and filter chips at the top (Available today, Under $20, 4.5+ stars). Tapping a card opens a detail screen with bio, reviews, and a “Request a walk” button. The request form collects dog name, date, time window, and a note, then shows a success state. Requests lists what the user sent with a status badge (Pending, Accepted). Use realistic mock data. Clean light theme with a blue accent. Out of scope: payments, chat, walker-side app, maps.

Expense splitter (fintech-lite)

Hypothesis: Roommates will log shared costs if settling up is one tap.

Build phase 1 of a shared-expense app called Evenly. Navigation: a stack starting at Groups. Groups lists groups with each one’s total and the user’s balance in green (owed) or red (owes). Group detail shows a balance summary at the top (“You owe Sam $24.50”) and an expense list below. An “Add expense” screen takes a description, amount, who paid, and who is included, split equally. A “Settle up” screen lists each balance with a “Mark as paid” button that zeroes it and adds a settlement row to the history. Seed one group of 3 roommates with 8 expenses. Store on-device. Neutral light theme, tabular numbers. Out of scope: real payments, bank connections, currencies, receipts.

Appointment booking

Hypothesis: Clients of a solo stylist will book online instead of messaging.

Build phase 1 of a booking app for a single hair stylist called Chair. Navigation: bottom tabs for Book and My bookings. Book lists 5 services with duration and price. Choosing one opens a date strip for the next 14 days and a grid of available 30-minute slots, with booked slots greyed out. A confirm screen shows the service, time, and price, collects name and phone, and ends in a confirmation state. My bookings lists upcoming bookings with a Cancel button that asks for confirmation. Use mock availability. Soft neutral theme with a terracotta accent. Out of scope: payments, deposits, stylist admin, calendar sync.

Workout log

Hypothesis: Lifters will log every set if logging a set takes two taps.

Build phase 1 of a strength log called SetLog. Navigation: bottom tabs for Today, History, and Progress. Today shows the current workout as a list of exercises; tapping one opens a sheet with the last session’s weight and reps prefilled and a big “Log set” button, plus steppers to adjust. History lists past workouts by date with total volume. Progress shows a line chart of best weight over time for one selected exercise. Seed 4 weeks of history for squat, bench press, and deadlift. Store on-device. Dark theme, orange accent, large numerals. Out of scope: programs, timers, social, wearables.

Flashcards

Hypothesis: Students will review daily if a session takes under three minutes.

Build phase 1 of a flashcard app called Recall. Navigation: a stack starting at Decks. Decks lists decks with card count and how many are due today. Study shows one card at a time: tap to flip, then “Again”, “Good”, or “Easy” buttons that schedule the card and move to the next. An “Add card” screen takes front and back text. A results screen after the session shows cards reviewed, percent correct, and the current daily streak. Seed two decks of 20 cards (Spanish verbs, biology terms). Store on-device. Calm light theme. Out of scope: images, audio, sharing decks, sign-in.

Event RSVP

Hypothesis: A meetup organizer’s members will RSVP in-app instead of in a group chat.

Build phase 1 of an event app for a running club called RunClub. Navigation: bottom tabs for Events and My RSVPs. Events lists upcoming runs with date, meeting point, distance, pace group, and spots left. Event detail shows a description, a list of attendee initials, and a “Count me in” button that turns into “You’re going” and reduces spots left. An RSVP sheet asks for pace group and an optional note. My RSVPs lists events the user joined with a Leave button. Seed 6 events over the next month. Bright light theme with a lime accent. Out of scope: payments, maps, chat, organizer tools.

Follow-up prompts for the first build

First builds rarely fail outright. They miss in small, predictable ways. One change per prompt, with “change nothing else” where it matters, keeps each edit from disturbing screens that already work.

A control is too small or in the wrong place

On the Today screen, make the check button 56 points tall and pin it to the right edge of each row. Change nothing else.

The mock data looks fake

Replace the mock data with 12 realistic entries for dog walkers in Austin: varied names, prices between $15 and $35, ratings between 4.1 and 4.9, and short bios in different voices.

A screen is blank on first launch

Add an empty state to My bookings: one sentence explaining what will appear here and one button that goes to the Book tab.

A button does nothing

The “Mark as paid” button does nothing when tapped. Make it set that balance to zero, add a settlement row to the history, and show a short confirmation toast.

Everything feels cramped

Use 16 points of padding on every screen edge, 12 points between cards, and make sure no text is smaller than 13 points. Keep the layout otherwise the same.

The hypothesis now needs shared data

Store walk requests in my connected Supabase database so a request created on one phone shows up on another. Keep the same screens and fields.

If a follow-up keeps failing, the prompt is usually describing an outcome (“make it better”) instead of a change you could check. See how to write prompts that produce better React Native code for more patterns.

The cut list: what a 24-hour MVP leaves out

No sign-in, unless identity is what you are testing.
No real payments, unless willingness to pay is what you are testing. A “Mark as paid” button tells you whether people reach the moment of paying.
No onboarding carousel. If the core action needs explaining, the core action is the problem.
No settings beyond what the core action needs.
No second user type. For a marketplace, fake the supply side with realistic mock providers.
No more than five screens.

The five-screen limit is also practical: ShipNative’s free plan caps a single build at five screens, and every prompt above is four, so the first build fits with one screen to spare.

How to run the five-person test

Five testers won’t give you statistics. They will show you every place the core action is unclear, and that’s what the first day needs.

Give a situation and a goal, not instructions: “You just paid for groceries for the flat. Use this to make sure you get paid back.”
Hand over the phone and say nothing until they finish or give up.
Write down three things: where they paused for more than a couple of seconds, anything they tapped that wasn’t interactive, and whether they finished.
Only after they finish, ask one question: “What did you expect to happen?”

Fix what two or more people got stuck on. Log everything else as a note, not a task. When a tester asks for a feature, write down the problem behind the request. That problem is useful later. The feature usually isn’t.

After day one

If the hypothesis held, the next step is making it real: accounts, a database, and a build testers can install. The guide to adding a real database covers the data side, and TestFlight for AI-generated apps covers getting it onto testers’ phones without Expo Go.