Smaller than you think. The first version of a product has one job: prove that real people will use it for one real problem. Everything that doesn't serve that job can wait.
Why first versions grow too big
Founders know their idea in full, so it feels incomplete to launch without the dashboard, the loyalty points, the admin reports and the dark mode. Each feature is reasonable on its own. Together, they turn a test into a long, expensive build, and you learn nothing until the end.
The risk isn't that the first version looks too simple. It is that you spend your budget building things nobody needed, and have little left when you discover what they actually want.
Find the one sentence
Before listing features, finish this sentence: "A (specific person) can (do one thing) so that (clear result)." For example: "A café owner can see yesterday's sales from every branch on their phone, so they stop calling each manager at night."
If you can't write the sentence, the product isn't ready to build yet. If you can, every feature gets one test: does it help that person do that thing? If not, it goes on the later list.
What usually belongs in version one
- The single path a user takes to get the result, start to finish.
- Just enough sign-in and settings to make that path work.
- A simple way to see whether people use it, and where they stop.
- A way for users to tell you what's missing.
What usually waits
- Admin tools you can do by hand for the first few customers.
- Integrations you can replace with a manual step for now.
- Edge cases that affect a handful of users.
- Polish on screens few people will visit.
Doing things by hand at first is not a failure. It is how you learn which parts are worth automating.
Small is not the same as poor
A small first version should still be solid. The one path it offers must be reliable, fast, secure and pleasant to use, and it should work in the languages your users speak. Cutting scope is good; cutting quality on what remains is not. People forgive missing features far more easily than broken ones.
Plan the second step, too
Write down what you expect to learn from the first version and what you will build next if you are right, or if you are wrong. That keeps the first release honest: it is the start of a sequence, not a smaller version of the dream.
The short version
Your first version should be the smallest thing that lets a real person solve a real problem and tells you whether it worked. Keep it narrow, keep it solid, and let what users do decide what you build next. If you have an idea and want to find its first version, try the Solution Architect.