TL;DR: A good MVP is not a smaller version of the full product. It is the one loop that proves someone wants this, built properly, with almost everything around it cut. Keep the core action, the thing that makes a user say "oh, that worked," and the few foundations that are expensive to add later: account ownership, a version header on every API call, basic analytics and a way to take payment if money is part of the test. Cut settings, admin panels, roles and permissions, second platforms, social features, custom design systems and every "while we're at it" integration. I have shipped a lot of version ones, for my own products like LectureNotes AI and Lifemaxxing AI and for clients as a freelancer and fractional CTO, and the ones that worked all had a short list of things they did and a much longer list of things they deliberately did not.
The most common conversation I have with a founder at the start of a project is not about technology. It is about the feature list. They arrive with twenty items, all of which feel essential, and the job in the first call is to find the two or three that actually test the idea and park the rest. That is not me trying to do less work. It is that every extra feature in a version one delays the only thing that matters, which is real users touching the product and telling you, with their behaviour, whether you are right.
What an MVP is actually for
An MVP exists to answer one question as cheaply and quickly as possible: will the people you think have this problem use the thing you built to solve it? Everything that does not help answer that question is cost without information.
That framing changes how you judge features. "Would users like this?" is the wrong test, because users would like almost anything. The right test is "if we leave this out, can we still learn whether the core idea works?" If the answer is yes, it waits.
It also means the MVP has to be good at the one thing it does. Minimum does not mean broken. A version one that technically exists but fails at the core action teaches you nothing, because you cannot tell whether people rejected the idea or the bugs.
Find the one loop
Every product that works has a core loop: the action a user takes and the result they get back. Version one should be that loop, end to end, and very little else.
For LectureNotes AI the loop was: open the app, record the lecture, get back a summary, the key takeaways and a clean outline. That is the whole promise in one sentence, and it is why the product could spread the way it did, which I wrote about in the retrospective on 15 million organic Instagram views. If a student had to set up folders, pick a template and choose a summary style before they got any notes, most of them would never have reached the moment that made them tell a friend.
For an AI voice agent the loop is a phone call that ends with something useful done: a booking made, a lead captured, a question answered. The temptation is to build five agents and a dashboard before a single real caller has heard one. In how many voice agents you actually need I argue for starting with one agent that does one job well, and the reasoning is the same as any MVP: prove the loop, then widen it.
A useful exercise: write the loop as a single sentence starting with "A user..." and ending with the result they get. If you cannot, the scope is not ready yet. If you can, every feature on the list either serves that sentence or it waits.
What I almost always cut
These come up on nearly every feature list, and in a version one they nearly always wait.
Settings and preferences
Every setting is a decision the team avoided making. In an MVP, make the decision. Pick the sensible default, ship it, and add a setting only when real users ask for a different behaviour often enough to matter.
Admin panels and internal dashboards
Founders want a polished back office from day one. In the early weeks the database console, a spreadsheet export or a simple read-only page is usually enough. Build the admin tool when the manual work it replaces is costing real hours, not before. The exception is when the dashboard is the product, as it was for VoiceDash, where the client-facing portal is the thing being sold.
Roles, permissions and teams
Multi-user accounts with roles are a large amount of work and a large surface for bugs. Unless the product is sold to teams from the first customer, one user per account is fine to start.
A second platform
Launching on iOS, Android and web at once triples the testing and the release work. Pick the platform where your users already are and ship there first, and plan for store review from day one. If you are unsure which stack makes adding the others easier later, I covered that trade-off in React Native vs Flutter vs native for a startup app.
Social and community features
Comments, profiles, following, sharing feeds. These need an existing crowd to feel alive, and an MVP does not have one yet. A plain share link that shows off the result usually does more for growth than a social layer nobody is using.
A custom design system
Use a solid component library and a clean, consistent layout. A bespoke design system is worth building once you know which screens survive contact with users. Most of the ones you design upfront will change.
"While we're at it" integrations
Every integration is a dependency you now have to keep working. In voice projects I see this constantly: the client wants the agent connected to the CRM, the calendar, the SMS tool, Slack and a reporting sheet on day one. Connect what the core loop needs. The rest can be added once the loop is proven, and I have written about how post-call automations break when too many are bolted on at once.
What I refuse to cut
Some things look like polish but are actually foundations. Skipping them saves a day now and costs weeks later, usually at the worst moment.
Ownership of accounts and code
The repository, the cloud project, the app store accounts, the domain and any AI or voice platform accounts should belong to the founder from the first day. This costs nothing in a version one and is painful to untangle after. When I inherit a codebase, account ownership is one of the first things I check, because it is so often wrong.
A version header and an additive API
If there is a mobile app, old versions will stay on people's phones long after you ship new ones. Sending the app version on every request and treating the API as additive from the start is a small decision that saves you from breaking live users later. The full reasoning is in designing a backend for app versions you cannot force-update.
Basic analytics on the loop
You are running an experiment, so you need to see the result. That does not mean a full analytics stack. It means a handful of events on the core loop: signed up, started the action, got the result, came back. Without those, you are guessing.
Payments, if money is part of the question
If the thing you need to learn is whether people will pay, a payment step is part of the MVP, not a later feature. Free usage and paid usage are different signals. With LectureNotes AI the gap between views, users and paying users was the most useful lesson of the whole product, and you only see that gap if payment exists.
Cost visibility on AI features
For AI products, every user action has a real cost per call. A version one does not need a perfect cost model, but it needs to log usage per user so you know whether the unit economics can ever work. I went through how to think about this in AI app unit economics and cost per user.
How I run the cut with a founder
The process is simple and it works best on a call with the full list in front of us.
- Write the loop sentence. One sentence, one user, one result.
- Sort every feature into three columns: needed for the loop, foundation that is expensive to add later, and everything else.
- Challenge the first column. For each item, ask whether the loop still works without it. Many items move to the third column here.
- Keep the second column short and honest. Foundations are things like ownership, versioning, analytics and payments, not "a nice onboarding flow."
- Turn the third column into a ranked backlog, so nothing is lost and the founder can see it is parked, not refused.
This also makes the project easier to price. A version one with a short, testable scope is a good fit for a fixed price, while a sprawling list is not, which is a point I made in fixed price vs hourly vs retainer. For AI voice projects specifically, the same cut happens in the discovery call.
Signs your MVP is too big
A few warning signs I watch for:
- The build estimate is measured in months, not weeks.
- Nobody can describe the core loop in one sentence.
- The feature list includes things for users you do not have yet, like team admins or power users.
- More time is going into screens around the loop than into the loop itself.
- Launch keeps moving because "it just needs one more thing."
If two or more of these are true, the fastest way to go faster is usually to remove something, not to add people.
After version one
The point of cutting is not to stay small. It is to earn the right to build the next thing based on evidence. Once real users are moving through the loop, the backlog stops being a list of opinions and becomes a list of requests you can rank by how often people hit them. That is when settings, admin tools, second platforms and integrations come back, one at a time, each one justified by something users actually did.
Most of the products I have seen struggle did not fail because version one was too small. They failed because it took too long to reach anyone, and by the time it did, the team had spent their energy on features nobody had asked for.
I build software, mobile apps and AI voice agents for founders across the US, UK and Europe, and I help teams cut a feature list down to a version one that actually ships. If you have an idea and a list that keeps growing, more about my background here, or book a call and we can find the loop together.