A first version, or MVP, should include only what lets one type of user finish one core job, plus sign-up and login, payments if they pay, and a simple way for you to fix problems. Leave out second user groups, native apps, detailed reports, and anything you can do by hand for the first few months.
Most first versions go wrong in one of two directions. Some are too big: a feature list for year three, built before anyone has used year one. Others are too thin: a demo that looks like a product but can't take a real customer through a real job. The goal sits between them: small, but finished. Below: what every first version needs, what to leave out and what to do instead, a simple way to decide, what four real products launched with, and a worksheet you can fill in today.
MVP, prototype, or first version: the difference
| What it is | Real users? | |
|---|---|---|
| Prototype or demo | Screens that show the idea, often clickable | No: for pitching and feedback |
| First version (a real MVP) | The smallest product people can use and pay for | Yes: live, with real data |
| Full product | Several user types, many features, integrations | Yes: built up in phases |
This post is about the middle row: small enough to build in weeks, but complete enough that a stranger can sign up, pay, and get the job done without your help. A prototype can be built with no-code or AI tools, and that's often a smart first step, as covered in AI-built app or hire a developer.
What every first version must include
These are the parts that turn a demo into something a stranger can use without you on a call. Skip any of them, and it's still a demo.
- The core job, working end to end. Booking, ordering, sending, approving: whatever people come for, completely.
- Sign-up, login, and password reset. So people can come back to their own data.
- The records the job creates, stored safely. The order or booking still exists tomorrow.
- Payments, if people pay inside it. Including what happens when a card fails.
- A small admin view. Enough to see users and fix a stuck record, not a copy of the whole product.
- Basic emails. Welcome, confirmation, and password reset.
- Live hosting, backups, and error alerts. So you find out about problems before your users email you.
None of these are exciting, and none of them show up in a pitch deck. They're also exactly what separates a product people trust with their money and data from one they try once. Budget for them first, then add features with whatever is left.
What to leave out of a first version
| Feature | Do this instead, for now |
|---|---|
| A second type of user | Launch for the people who pay; serve others by hand |
| iOS and Android apps | A web product that works well in a phone's browser |
| Detailed reports and dashboards | A spreadsheet export, reviewed weekly |
| Teams, roles, and permissions | One account per person |
| Many integrations | Payments only; connect the rest once people ask |
| Settings and customization | One sensible default |
| Several languages or markets | One market, done well |
Mobile apps are the most common item on this list. Whether and when you need one is covered in do you need a mobile app.
Do it by hand before you build it
Many features exist to save time on something that happens often. In the first months, it doesn't happen often yet, so doing it by hand costs you an hour a week instead of weeks of building. It also shows you exactly how the feature should work before you pay for it.
- Approve new accounts yourself, from an email alert
- Send invoices from your accounting tool instead of in-app
- Onboard each early customer on a short call
- Export data to a spreadsheet instead of building reports
- Handle refunds and changes through the payment dashboard
Build the automated version when the manual one starts eating real time every week. By then you'll know the exact steps, the edge cases, and whether customers even care about it. Some features never reach that point, and those are the ones you were happiest not to build. Keep a simple note of each manual task and how long it takes. When one crosses an hour or two a week, it has earned its place in the next release.
How to decide which features make the cut
Put every feature on your list into one of three columns. Ask these questions of each one:
| Must work on day one | Can be done by hand | Can wait |
|---|---|---|
| Without it, users can't finish the core job | It's needed, but happens a few times a week | Users would still pay without it |
| It protects money or personal data | You can do it from an existing tool | It's for a user group you haven't launched to |
Be strict with the first column. For most products it holds five to ten features, and everything in it must work completely. The last column isn't a rejection list: it's the next release, in an order you'll decide once real users tell you what they miss.
When a first version needs to be bigger
Small is the right default, but a few kinds of products can't launch with one user type and one job. Plan for a larger first version, and a longer timeline, if yours is one of these:
- Marketplaces. Buyers and sellers both need their side working, or neither shows up. Start with one narrow category or one city instead of cutting a side.
- Products that handle health or financial data.Privacy and security requirements apply from the first user, and they add work you can't postpone.
- Tools sold to larger companies. Buyers may ask for team accounts, single sign-on, or a security review before they can sign.
Even then, the same method applies: sort the list, keep day one as small as the product allows, and do the rest by hand until it hurts. A bigger first version still launches sooner than a platform built for every future case, and it still teaches you what users actually need before you spend the rest of the budget.
What four real first versions launched with
Each of these launched around one clear job, then grew from there.
| Product | The core job | Result |
|---|---|---|
| Digital business card | Build a profile, share it with one tap | 30K+ users |
| School platform | Run attendance, fees, and parent messages in one place | 1,000+ students |
| Printing platform | Upload a file, pay, and get prints from the nearest branch | 400+ orders a day |
| AI chatbot SaaS | Add a chatbot that answers from your own website | 30+ businesses |
The chatbot: one install, one job
The Chat Company is a good example of a sharp core job. A business enters its website address, picks the pages the bot should learn, styles the chat window, and pastes one line of code. Everything in the build served that flow, and it now handles 100K+ messages a day. The school platform shows the other side: it needed staff, teachers, and parents from day one, which added to the build: it took ten weeks.
First version mistakes that cost the most
These are the patterns that most often turn an eight-week first version into a six-month one, or produce something nobody uses:
- Building for year three.Every role and market "so we don't have to rebuild". You'll rebuild the parts you guessed wrong anyway.
- Copying a competitor feature for feature. Their product took years to reach that list. Match their core job, then beat it on one thing they do badly.
- Rebuilding what you can rent. Custom payments, logins, or email when proven services exist.
- Polishing before launching. Weeks of design detail on screens users may never open.
- Going too thin. Skipping payments or data safety to save time, then launching a demo by accident.
- No way to fix things. No admin view at all, so every stuck record needs a developer.
The fix for all of these is the same: a written scope, agreed before the build, that names the user and the job. What that scope costs and how long it takes are in what a web product costs and how long a first version takes.
A worksheet to scope your first version
Fill this in before you talk to any developer. It takes about an hour, and it will make every quote you get sharper and cheaper: Leave a line blank rather than guess. A blank tells a developer where to ask, and a guess sends the quote in the wrong direction.
If you're not sure yet whether you need a product at all, start with website or web product. Otherwise, send your worksheet, or even just the raw feature list, and I'll help you sort it. See the kind of products I build on my SaaS and web products page, or get in touch. I'll send back the sorted list with a price and timeline for the first part.
