Your first app version should include the features needed for one specific user to complete one important task, plus the reliability and support that task requires. Build the steps from input to useful result. Leave extra audiences, optional integrations and unrelated outcomes for later.
“It just needs one more feature” can keep an app private for months.
And AI makes adding things feel deceptively easy. A screen appears quickly. Then you discover the empty state, permissions, errors, stored data and all the ways it connects to everything else.
The screen was the easy part.
How do you decide what belongs in version one?
Start with the user’s result and work backward.
Imagine a freelance designer who wants to record decisions from a client call and turn them into a follow-up message. This is a hypothetical example, not a validated product recommendation.
The first promise could be: “Turn your own call notes into an editable list of decisions and next actions that you can copy into an email.”
That promise suggests a short flow:
- Paste or enter notes.
- Create a draft summary.
- Review and correct the decisions and actions.
- Copy the approved message.
If AI drafts the summary, the review step is part of the product. You don’t want it quietly inventing a client commitment and sending it as fact.
The promise doesn’t yet require automatic recording, a meeting bot, a CRM, team workspaces or sending emails on the user’s behalf.
What is the easiest way to prioritise app features?
Put each proposed feature into one of three groups: necessary for the promised task, worth testing later, or outside the current product.
| Proposed feature | First-version decision | Reason |
|---|---|---|
| Enter notes | Include | The task needs an input |
| Edit the draft | Include | The user must correct the result |
| Copy the final text | Include | The result needs to leave the app |
| Explain a failed request | Include | A user needs a way to recover |
| Warn before losing unsaved work | Include if work would otherwise be lost | Protects the current task |
| Store every past call | Test later | Not part of this first promise |
| Connect to five CRMs | Leave out | Adds separate integrations and use cases |
| Team approval workflow | Leave out | Serves a different audience |
| Animated dashboard | Leave out | Doesn’t help produce the follow-up |
The word “include” doesn’t mean you must use a complicated implementation. A clear message and retry can sometimes handle a failure without a whole support system. Make the implementation fit the situation.
How do you avoid overbuilding when every feature seems useful?
Ask: “If I remove this, can the intended user still get the promised result?”
If yes, it is a candidate to postpone. If no, it belongs in the task or the promise needs to shrink.
Then set a time budget for the next useful release. Ryan Singer’s Set Boundaries chapter in Shape Up describes choosing how much time an effort deserves and adjusting scope around that constraint.
My practical version is to write what I intend to share at the end of the time available. If it doesn’t fit, I remove an optional outcome. I don’t remove the ability to correct a mistake or finish the task.
Keep a separate note for later ideas. It is a place to remember them, not a promise to build them all.
Do you need accounts, payments and notifications in the first version?
Only when the product’s actual job needs them.
Accounts may be necessary for shared or private stored information. They may add friction to a tool someone uses once to format text. Decide from the use case.
Payments belong when you are making a paid offer. You can test a paid manual service before building a full subscription product. If you do sell access in the app, the purchase and access experience need to work together.
Notifications belong when timing is part of the value. A reminder app may need them immediately. A note formatter probably doesn’t.
My 20 things your vibe coded app needs to hit $10K MRR post shows the operational work that can accompany a real product. Treat it as a prompt to inspect what applies to your app. A simple personal utility doesn’t automatically need the same systems as a paid multi-user service.
What should you give an AI app builder before it starts?
Give it a small brief with a clear finish line. You can adapt this example:
Build a first version for a freelance designer who writes client follow-ups after calls. The user enters notes, gets a draft list of decisions and next actions, edits it, and copies the result. Label generated text as a draft. Do not send messages. Do not add accounts, history, CRM integrations or team features. Show clear empty and error states. Before implementation, identify missing decisions and propose the smallest version that completes this workflow.
That brief makes scope visible. It also gives you something to check when the tool suggests adding more.
For choosing a building environment, see my vibe coding tools comparison. For the overall approach, use Simple, Lovable, Complete.
How do you know the first version is ready to share?
Test the version you will actually give someone. A preview that looked right yesterday isn’t enough.
- Can a new person understand what to do without your narration?
- Can they complete the main task with realistic input?
- Can they correct an ordinary mistake?
- Does saved work behave as promised when they return?
- Are failures explained without trapping them?
- Are any accounts, payments and private data handled correctly for this release?
- Is there a clear way to report a problem?
Then invite a small group of relevant users. Observe where they get stuck and whether they use the result. Expand the audience as the evidence and product justify it.
That is what I mean by ship ugly and fast, but useful.
Frequently asked questions about first-version features
How many features should a first app have?
There isn’t a useful universal number. Three features can hide enormous complexity, while a handful of simple controls can complete one task. Map the user journey and count the promises and dependencies you are taking on. The result matters more than the number of bullets.
Should onboarding be part of version one?
Helping people start belongs in version one. That may mean one clear sentence and a useful example rather than a multi-screen tour. Watch a new user. Add guidance where they need it, and remove setup that doesn’t help them reach the result.
Should I build for web, iPhone and Android at once?
Usually choose the smallest platform scope that lets your intended users do the job properly. Ask where the task happens and which device capabilities it needs. Supporting several platforms creates additional work to build, test and maintain before you know what users value.
Can I handle part of the app manually at first?
Yes, if the manual process can reliably deliver what you promised and users understand relevant limitations. A manual step can help test demand before you automate it. Keep track of the time required so you know whether the service can support more users.
What if users request more features before trying it?
Ask what task the feature would help them complete. It may reveal a missing core step, or it may be an idea they won’t use. Investigate the recent situation behind the request before changing scope. Don’t turn every conversation into a new commitment.
What should I do if I have already overbuilt?
Write the current core promise and hide or postpone the parts that don’t support it. Get the main path working and test it. If you are stuck choosing what to cut, how to start before you feel ready is a useful reminder to make a bounded decision and act.
Should I keep building if no one uses the first version?
Return to the validation questions. Find out whether people understood the offer, reached the result and still preferred their old method. Build the next feature only when it addresses something you’ve learned.
Sources and further reading
- Ryan Singer: Shape Up, Set Boundaries, on time budgets and narrowing scope.
- Jason Cohen: Simple, Lovable, Complete, the product framework behind the release standard.