An MVP exists to test the one assumption that would sink the business if it were wrong. Almost everything else can be cut, faked or done by hand, except the few decisions you can't migrate out of later.
An MVP answers one question
Write the question down before anyone writes code. Will clinics pay for this? Will a stranger trust a record they didn't create? Will people come back in week two? If the team can't agree on the sentence, the scope will grow until it answers none of them.
Every feature then gets one test. Does the answer change if this is missing? If it doesn't, it waits.
That test cuts more than founders expect. It cuts the admin panel, the settings page, the second platform, the billing edge cases and most of the automation. A person can approve sign-ups by hand for the first hundred users. A spreadsheet can be the back office. None of that changes whether the product works for the person it's for.
Most of what you cut is cheap to add later
Cutting is safe when adding the thing later costs the same as adding it now. An admin screen built in month six costs what it would have in month one. By then you also know what it needs to show. Most reports and notifications work the same way.
So the default is to cut. The useful skill is spotting the few places where that default is wrong.
Some decisions get more expensive every week you defer them
These are the decisions where the cost of changing your mind grows with every user and every record. Three come up again and again.
Where your users' accounts live. The auth provider you pick on day one holds every password hash you'll ever have. Some providers won't hand them back. Amazon Cognito, for one, doesn't export password hashes, so moving off it means every user resets their password, or you migrate them one login at a time. That's fine for ten test users. At ten thousand it's a project. Choose a provider you could leave, or accept the lock-in on purpose.
Anything written somewhere public and permanent. If the product records things on a blockchain, the contracts that write those records are as close to final as software gets. In our ProofTap case study we put it this way: "A record published today is read by a client written in five years, against rules that were fixed when the record was made. There is no migration window and no deprecation notice." An MVP can skip the polish around those contracts. It can't skip deciding what they permit.
What a record means. Every table carries assumptions. One user per account, one currency, one timezone, one owner per document. Each is cheap to relax while there are a hundred rows. It's slow once there are a million and four services read them. You don't need to design for every future. You do need to know which assumptions you've made, so you can relax them before the data hardens around them.
AI makes the build fast and leaves the deciding slow
Code is cheaper to write than it has ever been. A small team with AI tools can put a working product in front of users far sooner than they could a few years ago. That's good for MVPs, because a faster build means more rounds of learning before the money runs out.
What the tools don't do is decide which question the MVP answers, or notice that the auth provider they reached for can't be left. Generated code also looks right whether or not it is. So the slow part of an MVP hasn't changed. Someone has to write down what the product must do, precisely enough to check. And someone has to make the few irreversible calls on purpose.
Before you start building
Write the question your MVP answers in one sentence. List what you're cutting. Then go through that list once more and ask, for each item, whether adding it in six months would cost more than adding it now. Most won't. The ones that do are where to spend the time.
That's the part we help with. We write down what the product must do, build it quickly with AI tools, and check it against that spec. Tell us what you're building.
