You Got a Build Result. Here's What Goes in Your v1

Quick check: is your result strong enough to scope?

Scoping only makes sense if the signal is real. Two numbers matter, listed below. If you're not sure your test was clean, our 7-day validation plan covers the test from day one. Everything below assumes you have a "build."

• Signup rate on cold traffic. According to Flowjam's waitlist benchmarks, 5 to 10% falls in a "healthy" band and 10 to 15% in a "strong" one. Flowjam also notes that warm traffic, like your own network, skews the rate higher than cold traffic would. So treat these as rough reference points and read only the strangers.
• Commitment after signup. This number matters more. Did people reply to your email, book a call, or pay a deposit? A signup costs nothing. A reply describing their problem costs time, and that's what you scope from.

Turn waitlist replies into a problem list

Your replies are the raw material for v1. Don't summarise them from memory. Put them in a sheet.

Sort every reply into three columns

Give each reply one row and fill the three columns below. Then count. Which problem comes up most? That's your v1. The second most common problem is v2, even if it's the one you're most excited about.

• 1. The problem, in their exact words. "I lose track of which clients haven't paid" not "invoicing pain."
• 2. What they use today. Spreadsheet, WhatsApp, paper, a competitor, nothing.
• 3. What they'd need to switch. Anything they said about price, speed, or "if it just did X."

Example: one problem, one outcome

Say you're building for independent personal trainers. Your replies mention three things: chasing clients who miss payments, scheduling sessions, and tracking client progress. If most replies mention payments, v1 is "trainers get paid on time without awkward messages." Scheduling and progress tracking wait. The current workaround tells you the bar to beat. If they use a spreadsheet, your v1 just has to be clearly easier than a spreadsheet. It doesn't need to beat a full platform.

What to keep, what to cut, what to postpone

Use this list on every feature idea, yours and your signups'. Want to see what a single feature adds to scope? Our feature costs guides break them down one by one, and the app feature cost estimator lets you test a list.

• Directly delivers the main outcome. Decision: keep. Why: it's the reason people signed up.
• Needed so a user can reach that outcome (sign up, log in, onboarding). Decision: keep. Why: without it, nobody gets to the core loop.
• Payment, if you'll charge from launch. Decision: keep. Why: revenue is the next thing you need to test.
• Mentioned by one or two signups only. Decision: postpone. Why: real, but not your main signal yet.
• Nobody mentioned it. Decision: cut. Why: you'd be guessing again.
• Admin dashboards, analytics, settings pages. Decision: postpone. Why: you can do these by hand for your first users.
• Social features, chat, sharing. Decision: cut, unless the outcome needs them. Why: expensive and rarely the core loop.

The "manual first" rule

For anything in the "postpone" column, ask: can I do this by hand for the first users? Sending reminders yourself, approving accounts manually, exporting data to a spreadsheet. If yes, it's not in v1. You'll learn which parts are worth automating from real usage.

How to order your v1 features

Order matters because it decides what gets built, tested and polished first. Build in the order a user experiences the app. Write each feature as one sentence starting with "A user can…". If you can't write the sentence, the feature isn't clear enough to build.

• 1. The core action. The one screen or flow that delivers the outcome. In the trainer example, sending a payment request and seeing who paid.
• 2. Access. Sign up, log in, a short onboarding that gets the user to the core action fast.
• 3. Payment, if you charge from day one.
• 4. The minimum around it. Notifications or emails only where the core loop breaks without them.
• 5. Store submission and launch setup.

What fits in an MVP built in about 20 days

This is where a scope becomes real. Our MVP Development service is built around a v1 like the one above. The standard package covers:

• Core product features scoped for v1 launch
• iOS, Android and responsive web
• User authentication and onboarding
• Stripe or payment integration
• Database and API setup
• Mobile first UI design
• App Store and Google Play submission support

What that looks like in practice

That list maps almost exactly to the build order: one core loop, access, payment, launch. Projects on our projects page show what that looks like in practice. Sober Bet, a betting addiction recovery app with community support, shipped on iOS and Android in 20 days. Pet Care Business, a B2B tool for pet industry professionals to track and manage business data, shipped on the web in 20 days. If your scope includes things like marketplaces, multi-tenant setups or compliance requirements, that's a bigger build. The same page explains that these get a custom quote and a phased roadmap instead. For a standard v1: your app on the web, iOS and Android, fixed at $3,460, delivered in about 20 days. Design is included, you see progress every week, the code is 100% yours on your GitHub, and you get 2 weeks of fixes after launch. Have your problem list ready? Book a call. Free, 30 minutes, with a fixed quote before any code is written.

When to launch to your waitlist

Your waitlist is your first user test, so time it well. Don't wait for the waitlist to cool down. The longer the gap between signup and launch, the less people remember why they signed up. After launch, our post-launch guides cover what to track and what to build next.

• Launch when the core loop works end to end. A user can sign up, do the main action and get the outcome. Polish can wait. Broken flows can't.
• Go to the people who replied first. They described the problem, so they'll tell you fastest whether you solved it. Invite them personally, then email the rest of the list.
• Ask one question. "Did this solve the problem you told us about?" Their answers decide what comes out of the "postpone" column next.
• Launch inside your fix window. If your build includes post-launch fixes, launch early in that window so real usage reveals issues while they're covered.

Your one-page v1 brief

Before talking to any developer, put this on one page. That page makes any quote faster and more accurate, and it keeps scope from creeping during the build.

• The problem, quoted from your replies
• The user, as specific as your signups were
• The outcome, one sentence
• Feature list, each as "A user can…", in build order
• Platforms: web, iOS, Android, or a mix
• Payment: yes or no at launch
• Postponed list, so nobody forgets it but nobody builds it yet

Get a fixed quote for your v1

Know what your v1 should do? Book a call. It's a free 30-minute call, and you get a fixed quote before any code is written.

How many features should an MVP have?

As few as it takes to deliver one outcome. That usually means the core action, sign up and onboarding, and payment if you charge. If a feature doesn't help a user reach the main outcome, it belongs on the postponed list.

What if my signups asked for different things?

Count them. Build for the problem the largest group of committed signups described. The others go to the postponed list, and your launch feedback will show which one to build next.

Should I build for web or mobile first?

Look at where your users described the problem happening. On the go, mobile. At a desk, web. Our build an app guide covers both options.

When should I tell my waitlist the app is live?

As soon as the core loop works end to end. Invite the people who replied first, then the rest of the list.