One flow, seven days: how to get your app idea into someone's hand
A practical way to build a mobile MVP in a week: pick the single flow that proves the idea, cut everything else on purpose, and learn from people holding a real phone.
Most first versions of an app aren't minimal. They have a login screen, a settings page, an onboarding carousel and a pricing screen, and the one thing the app is actually for sits somewhere in the middle. They take months, and by the time anyone outside the team holds one, the budget and the excitement have both run low.
There's a faster way to find out whether an idea works: build only the part that proves it, put it on a real phone, and hand that phone to someone. That fits in a week. This is how we approach it.
Start with one sentence
Before any screens, write the app as a single sentence:
A specific person opens the app to do one thing and leaves with a result they care about.
If you can't fill it in, the idea needs more thinking, not more code. If you can fill it in three different ways, pick one. The other two are version two.
Say you're building a meal-planning app. "Busy parents plan meals" is too vague to build. "A parent opens the app on Sunday evening, takes a photo of the fridge, and leaves with five dinners and a shopping list" is a flow you can build, test and argue about. (That one is an illustration, not a client project, but it's the shape we look for.)
That sentence becomes the whole brief. Every decision during the week gets checked against it: does this help the parent get from the fridge photo to the shopping list? If not, it waits.
The cut list
The hard part of a seven-day build isn't the code. It's saying no to things that feel essential. Here's what we usually leave out of week one, and what stands in for each:
- Sign-up and loginone demo account, already signed in
- Onboarding screensa single line on the first screen, or nothing
- Settingssensible defaults for the person in your sentence
- Payments and subscriptionsa plain "Upgrade" screen with no checkout behind it
- Both platformsthe one your first users actually carry
- An admin panela spreadsheet or a file we edit by hand
- Every edge casethe happy path, plus the one failure people will definitely hit
None of these are unimportant. They're just not what you're testing yet, and each one you add to week one pushes back the moment someone holds the app.
Make the AI part real, and keep it on the phone
If your idea depends on AI, that part can't be a slide that says "AI happens here". It's usually what people are most skeptical about, so it's exactly what the prototype has to show.
Running the model on the phone itself makes that much easier in a week:
- Nothing to set up. No servers, no API keys, and no usage bills while you're still finding out if anyone wants this.
- It answers instantly, which decides a lot of whether AI feels useful or feels like waiting.
- It works in airplane mode, so the demo doesn't depend on the Wi-Fi in a café or a meeting room.
- Personal data stays on the device, which is easier to explain to the first people you test with.
iPhones that support Apple Intelligence give apps a free on-device language model, and a growing list of Android phones offer Gemini Nano. For narrower jobs, like recognizing what's in a photo, a small Core ML or LiteRT model is often enough.
On-device models have real limits. They're smaller than the big cloud models, they take shorter inputs, and they don't run on every phone. When an idea needs more than that, we use a cloud model for the prototype and say so plainly, so nobody mistakes the demo for something it isn't.
The week, day by day
- Day 1The sentence and a sketch
A 30-minute call to agree on the sentence and on what "done" means for day 7. Then a rough sketch of the three or four screens the flow needs, on paper. No design files yet.
- Day 2Screens, in code
We build the screens straight in SwiftUI, Jetpack Compose or Flutter. Something that runs on a phone teaches more than a polished mockup, and nothing has to be rebuilt later.
- Day 3Real data
The placeholder text goes and real content comes in: your recipes, your product list, real photos. Fake data hides the problems that matter, like a long name that breaks a layout.
- Day 4On your phone
A test build arrives through TestFlight or as an APK. This is the most useful day of the week. You use it on the bus, at your desk, in bad light, and notice things nobody spots on a laptop screen.
- Day 5Fix what felt wrong
Day 4 always turns up a handful of moments that felt slow, confusing or fiddly. Day 5 is for those, in order of how much they got in the way.
- Day 6The rough edges that count
Not polish for its own sake. An empty state so the first screen isn't blank, a loading state so a pause doesn't look like a crash, and one clear message for the error people will actually hit.
- Day 7Hand it over
A final build, and one page covering what we learned, what we'd build next, and what we'd leave out a while longer.
Day 8 is the real test
A week-one app isn't for the App Store. It's for watching five people use it.
Find five people who match your sentence. Hand each of them the phone, tell them in one line what the app is for, and then stop talking. Watch where their thumb goes. Notice where they pause, where they tap something that isn't a button, and where they smile.
Afterwards, ask three things:
- What did you think it would do when you first saw it?
- Where did you get stuck?
- What did you try to do next?
The last question is the one that matters. If people finish the flow and immediately try the next thing, like sharing the shopping list or saving a dinner for next week, that's your version one. If they put the phone down politely, you've learned that in a week instead of a quarter. Both answers are worth having.
When seven days isn't the right fit
Some ideas can't be proven in a week, and it's better to say so up front:
- The value only shows up with lots of users, like a marketplace or a social app that needs a crowd before it's interesting.
- The core depends on hardware or a partner integration you can't get access to yet.
- It only means something with regulated data, like real health records or real payments.
- The AI needs a model that won't fit on a phone, and no hosted option is good enough yet.
None of that makes them bad ideas. They need a different first step, usually a small test of the riskiest part on its own. If that's your situation, we'll tell you on the first call.