The features that matter for an MVP built with AI tools are the ones that let you test your actual thesis with real users: working authentication, a real database that stores real data, and one core workflow done properly. Everything else, including visual polish and edge-case handling, can wait until you know the thesis is worth building on. This isn't a technical question. It's a prioritisation question, and it's the one most non-technical founders get wrong in both directions.

Why "what features matter" is really a prioritisation question

When I first spec'd my product idea in a Google Sheets doc, I had 34 rows. Authentication was on there. So it was a database. So was social login, a referral system, an admin dashboard with usage analytics, email notifications, a settings page with theme options, and onboarding tooltips. Every row felt necessary at the time. None of them was, not for version one.

The mistake wasn't listing too many features. Spec'ing everything out is the right instinct, and I'd do it again. The mistake was treating the list as a build order instead of a menu to cut from. Every feature on that sheet answered the question, "What would a finished product need?" Almost none of them answered the actual question: "What does the first version need to prove the idea works?"

Those are different questions with different answers, and AI tools make this confusion worse before they make it better. When a platform can generate a notifications system or a referral flow in the same afternoon as your auth logic, "can I build this?" stops being the constraint. "Should this be in version one?" becomes the whole game. The technical barrier that used to force prioritisation by default is gone. You have to prioritise on purpose now.

The three features every MVP needs, regardless of what you're building

Strip away the category, the audience, the business model, and every real MVP needs the same three things.

Working authentication. Users need to sign up, log in, and have their data tied to their account rather than floating around unattached. This sounds basic, and it's the single most common gap in "MVPs" that aren't yet functional. If a user can't return to the product and find their own data waiting for them, you don't have a product. You have a demo.

A real database that stores real data. Not a spreadsheet standing in for one, not local storage that disappears when someone closes their browser. What a user creates, submits, or pays for needs to persist somewhere reliable, be retrievable the next time they log in, and be safe from disappearing if your server restarts. This is what a real backend actually includes, and it's worth understanding the basics before you evaluate any tool.

One core workflow done well. Not five workflows were done adequately. Pick the single sequence of actions that represents the value your product delivers from start to finish, and ensure a user can complete it without friction. For a task manager, that's creating a task, marking it done, and seeing it reflected accurately. For a marketplace, that's browsing, selecting, and completing a transaction. Everything your product eventually does branches off from this one path. Get the branch wrong, and it doesn't matter how polished the rest is.

Those three things are non-negotiable. Almost everything else is a judgment call, and most of the judgment calls should go the other way from what your spreadsheet wants.

The features that feel essential but usually aren't (yet)

Here's the list I cut from my own spreadsheet and the reasoning that got me there.

Admin dashboards. You are the admin at this stage. You can look directly at your database. Building a dashboard to view data you can already see is solving a problem you don't have yet.

Notifications, whether email or in-app. These matter once you have retention to protect. At the start, you have five users you can message directly if something needs their attention. Automating a problem you're currently solving by hand is premature.

Multiple user roles and permissions. If your product genuinely needs an admin role, a manager role, and a viewer role from day one, that's a real requirement, not a nice-to-have. But most non-technical founders add role complexity because it feels like what a "real" product has, rather than because their first 10 users need it.

Settings pages and customisation options. Founders love these because they feel like generosity. Users at the MVP stage don't want options. They want the thing to work.

Onboarding flows, tooltips, and empty states are polished to a fine finish. These matter enormously once you have consistent signups and you're losing people in the first five minutes. Before that, you're the onboarding. Walk your first users through it yourself and take notes on where they get confused. That's more useful data than any tooltip you could design in advance.

None of these is wrong to build eventually. They're wrong to build first, because building them delays the moment you find out whether anyone wants the core thing at all.

How to tell if a feature is validating your thesis or just delaying it

This is the honest, harder version of "just build the core workflow," which is easy advice to give and genuinely difficult to follow. The trouble is that you often can't tell which features are core until you've talked to actual users, and no framework replaces that conversation. What follows is a filter, not a substitute for it.

Ask two questions about anything on your list.

Does this feature let a user complete the core workflow, or does it sit around the edges of it? Authentication lets someone use the product at all. A referral system sits on the edges, dressing up the product before you know whether it's worth referring anyone to.

Does building this feature teach you something you don't already know, or does it just make the product feel more finished? A working payment flow teaches you whether people will actually pay. A custom-branded email template teaches you nothing you didn't already know.

If a feature fails both questions, it's a descoration. Decoration is fine once you know the thing underneath it works. Before that, it's just a more expensive way to delay finding out.

What AI tools make it easy now that used to force trade-offs

From 2025 to 2026, AI tools will have made certain features (authentication, basic payments, simple database structures) cheap enough to include by default, and that changes what "minimum viable" actually means compared to a few years ago. This is worth sitting with because it runs counter to the instinct to treat auth and a database as "stretch goals", the way I originally budgeted for them.

On my Fiverr spec, back when I was pricing this out with a developer, authentication and a proper database were treated as separate line items with separate costs, the kind of thing you'd consider descoping if the budget got tight. That framing made sense in a world where every feature cost developer hours. It doesn't make sense anymore, and carrying it forward into how you plan an AI-built MVP will make you cut the wrong things.

When I built my product on Mayson, working authentication and a real database weren't things I negotiated for. They were part of what the platform generated from the initial prompt, the same pass as the core workflow itself. That changed the actual question I was answering when I planned version one. I wasn't asking "can I afford real auth this time?" I was asking, "Does this specific feature help me learn something, or is it just there to look complete?" The trade-off that used to force the first question doesn't force it anymore. The second question is the one that's actually left, and it's a better question to be spending your time on.

If you're comparing platforms for your own build, it's worth knowing what questions to ask before picking a platform before you commit to one, since not every tool treats a real backend as the default in the way this changes. Mayson's free tier (10 credits, no credit card required) is enough to test this yourself against your own feature list before you decide what belongs in version one.

A simple framework for deciding what goes in v1

Y Combinator's Michael Seibel makes a related point in the YC startup library: an MVP's whole job is to find out whether a small group of early users get any value out of what you've built, nothing more ambitious than that. That's a useful gut check to hold your own list against.

Here's how I'd apply it, in order.

Write the full list first. Every feature you can imagine the finished product having. Don't self-censor at this stage. This is what the spreadsheet is for.

Circle the one core workflow. The single sequence a user completes that represents the value you're delivering. If you can't circle just one, that's worth sitting with before you build anything.

Mark authentication and data persistence as fixed costs, not optional line items. They're part of the workflow, being real, not additions to it.

Run everything else through the two questions from the section above. Core path or edges. Teaches you something or just looks finished.

Cut whatever fails both. Do not defer to "phase two" with a plan and a timeline. Actually cut it, and let it earn its way back in once real users tell you it's missing.

Build what's left. It will look smaller than your spreadsheet intended. That's correct. My professor, Wendy Alderton, used to say the feature list is a wish list until a user tells you otherwise. Nobody has told you otherwise yet. That's what version one is for finding out.

FAQ

Abhishek is a strategy consultant and non-technical founder who shipped his first SaaS product over a weekend in 2025, after a long false start. He still consults during the week. He writes about the practical mechanics of building without a technical co-founder.