Keep the task and what it needs. Save useful extras for later; leave unrelated features out.
A first version needs what lets the people it serves finish one useful task, plus the access and checks that task depends on. Everything else waits or stays out. Three questions sort each item.
What must your app help someone do?
Write one sentence a stranger could check: who the app is for, where they start, and the useful result they leave with. Everything else on your list is measured against that sentence. Write it before you open a tool or a list of features.
Name four things in plain words. The person: who is this for? The problem: what is hard for them today? Where they start: what do they have or know when they arrive? What "done" looks like: what can they do, or hold, when it works?
Here is one sentence for a directory: "A visitor can find a provider and contact them." You can check that sentence. You cannot check "a platform for local services".
One task does not mean one kind of account. An app that promises a match between two sides, such as a marketplace, may need both sides to be able to do their part.
The sentence also helps you resist the pull the other way. In September 2026 a founder writing about a launch described resisting "adding features just because I can build them." That is one founder's account, and we cannot check what came of it.
This step is adapted from our own playbook for first versions.
Not sure the idea is worth building yet? Start with Is your app idea worth building?. Still choosing who builds it? See Choose how to build your app.
What belongs in the first version?
The steps that complete the task, and what those steps lean on. "Small" here means a bounded useful flow, not a low screen count. A short flow can still need several screens.
Ask three questions of every item on your list.
Does removing it stop the task you promised? If yes, keep it. For a directory, finding a listing is the task.
Does removing it break the access the task needs? Access means who gets in and who sees which data. If yes, keep it. If only providers may change their own listing, that rule is part of the access.
Does removing it stop you running the app responsibly? That means a wrong entry can be fixed, and a bad input does not mislead people or lose their data. If yes, keep it. A way to fix a wrong listing is an example.
If all three answers are "no", the item is not part of the first version. It goes on the later list, or it is out.
- Later: you can name a real reason a user will want it once people use the app. A booking calendar for a contact directory is one.
- Out: it does not serve this app's task at all. A social feed for a contact directory is one.
Go through your list one item at a time, in this order, and write Keep, Later or Out beside each. Do it today with the list you have.
These questions are our own method, not a proven number of features. They do not say that login, payments or an admin side are in or out. They ask whether your task needs them. If it does, read Is your AI-built app safe? for access and security, and the guide to login and user roles.
What can wait until later?
An item can wait only if the task you promised, the access it needs and running the app still work without it. Here is the test on one example. Take each row and ask the three questions.
Illustrative example, not a client case: a directory where visitors find a provider and contact them.
| Item | Does removing it stop the task, the access or running it? | Call |
|---|---|---|
| Finding a relevant listing | Yes. That is the task. | Keep |
| Accurate contact details on each listing | Yes. Contact is the promise. | Keep |
| A way for you to add and fix listings | Yes. Wrong or stale details break the promise. A simple way is enough. This is where "by hand" starts. | Keep |
| Handling an empty search and bad input | Yes. Without it people hit dead ends and wrong results. | Keep |
| A booking calendar | No, while the promise is contact, not booking. | Later |
| Payments | No, while the app takes no payment and says so. | Later |
| Reviews and ratings | No. | Later |
| A social feed | No. It does not serve contact at all. | Out |
Change the promise and the calls change. If the directory promised "book and pay", the calendar and the payment flow stop being optional, and so does handling a failed payment. They cannot be deleted to make the list look short. A cut is a call about this app's promise. It is not a rule about payments, login or an admin side.
A founder building a directory wrote in November 2025 that it "does not process payments", because, in their words, they did not trust themselves. That is one founder's choice for a contact-only app, not a rule for yours.
Vako's public founder-story page (read 25 October 2026) shows a founder who weighed Bubble's learning curve and chose help. It also discusses matching by AI as something for later, once there is enough data. The page does not document an exact first-release cut list, and it does not say when the AI decision was made. Read it as one example of a "later" idea.
The short "what can wait" lists in Prototype, MVP or ready to launch? and the App Build Planner are summaries. This page is the method behind them. The first guide also sets out the stage definitions.
What can you do by hand for now?
Some automation can start as a person doing the job, if that is honest and you can keep it up. You add the listings yourself. You confirm a booking by message instead of through a calendar. A form sends you each entry, and you read it and act on it.
Two tests decide whether a manual step is fine:
- It must not mislead users. Say what happens. If you confirm bookings by message, the app should not look as if booking is instant.
- It must not put their data at risk. A person doing the job still has to handle the data with care.
Then ask whether you can keep it up if more people use the app than you expect.
Doing a step by hand does not remove your responsibility for payments, access or people's data. If your app takes money or holds private data, the app has to handle that properly. Take real payments in your app covers payments.
The directory founder in the last section is the illustration: a deliberate contact-only version. It does not pretend to handle transactions, and that is what honest looks like.
Doing a step by hand is a way to learn what users need before you build it. Do not assume it is cheaper or quicker. That depends on the job.
How do you check the first version works?
Write one acceptance sentence for the core task, then try it yourself as each role the task needs. Five checks, in order:
Write the sentence. "A visitor can find a listing and contact the provider." This checks that you know what "working" means.
Try it as each role. If the app has visitors and providers, do the task as both. This checks the task and the access you tried.
Leave and come back. Check the data is still there. This checks whether the data survives that return.
Try a bad input and a failure. An empty search, a wrong format, a declined payment if your app takes one. This helps reveal dead ends for the failures you tried.
Watch real people try it. This shows where they get stuck, which you cannot see yourself.
Passing these checks does not show that every access rule or failure case is handled.
A click-through demo that looks right is not a security check. For access and security, read Is your AI-built app safe?, and the guide to login and user roles. Before you open the app to the public, use The Launch List.
Expect the last stretch to take work. On 20 Feb 2026 a self-described founder described deployment, integrations and bugs arriving after AI-assisted progress. Their "80/20" wording is rhetoric, not a measured rate. In a separate discussion on 19 Jun 2026 a technical commenter warned about login, roles, billing and context once an app has real users. Treat these as one founder's account and one developer's warning.
In March 2026 a founder who promotes their own product wrote, "The first version worked, but it was still experimental." That is a founder's words about reliability, not proof of anything.
When does something move from later into the app?
Keep a short later list, and move an item in when you have seen a user need it, or when running the app needs it. Give each later item one line: the item, the reason it waits, and the sign that brings it back.
- Booking calendar. Waits because the promise is contact. Comes back when a third person asks for this.
- A manual step behind a form. Waits because it works by hand. Comes back when it takes too much of your week.
In August 2026 a founder looking back on a first product wrote, "I felt so productive building and adding features everywhere." Feeling productive is not the same as users needing the feature. Whether people want your app is a question for Is your app idea worth building?. A later list does not show that anyone wants it. It stops you adding things by habit.
A feature list is one input to a build plan. The App Build Planner makes the list from your idea. Check its output against your own acceptance sentence and the three questions. Building it yourself with AI? See How to build an app with AI.
Shaman AI's public page (read 25 October 2026) describes a web app, with mobile work after. The page does not say whether mobile was planned from the start. It shows a platform moving from later to now. It is not a rule that web comes first.
What should you do next?
Sorted your list and want a second pair of eyes on it? Get a free Price and Scope Check.
Send your idea or notes in any form. A person reviews them and sends back one page: what to cut, what it should cost as a range, how long it should take, and three questions to ask anyone who bids. It stops short of a fixed quote or a plan. For general costs, see What an app costs.
Already have something built? Get a Free Build Audit →
Questions.
How many features should my first version have?
There is no right number, and our evidence does not support one. Keep the whole task and what it needs, and name what is out. A long list is not wrong, and a short one is not safe. Sort each item with the three questions.
Does my first app need a login?
Your first version needs sign-in when the promised task needs to identify people or keep their information private. If it does, check the access rules as well as the sign-in screen. Is your AI-built app safe? covers access. Login and roles has more.
Can I leave payments out of my first version?
It depends on what you promise. A contact directory can be useful with no payments, if it says so. A "book and pay" app needs the payment flow and a plan for when a payment fails. Check your promise first. Take real payments in your app covers the detail.
Should my first version be on the web and on phones?
Only if the task needs both now. Shaman AI's public page (read 25 October 2026) describes a web app, with mobile work after. The page does not say that order was planned, and it is not a rule. Mobile or web app cost covers the trade-offs.
What if a feature is useful but not essential?
Put it on the later list. Give it a reason it waits and a sign that brings it back, such as a user asking for it. Do not add it quietly to the build. See when something moves into the app.
How do I turn my idea into a feature list?
Use the App Build Planner to make a list from your idea. Keep anything whose removal breaks the promised task, the access it needs or running the app responsibly. For everything else, decide whether it belongs on the later list or stays out. This guide helps you sort the list.