A more usable question is not what to cut, but what to fake.

Faking, here, means something specific. The feature exists from the user's point of view. It behaves correctly. It simply is not implemented the way it will eventually be implemented. A human does it. A spreadsheet does it. A scheduled job does it every hour instead of instantly. The user gets the outcome, and you do not yet pay for the machinery.

Done well, this is the single biggest lever on how fast a first version reaches real users. Done badly, it produces a demo that collapses the first week it meets traffic.

What is safe to fake

Anything where the value is the outcome and not the mechanism.

Matching and recommendations are the clearest example. The first version of almost every marketplace matching engine should be a person with a list. If ten matches a day need making, a human makes better matches than your first algorithm will, and you learn what the rules actually are by watching someone apply them.

Onboarding and verification are usually safe. A document check that will eventually be automated can start as a queue that somebody works through each morning. Users care that their account is approved by lunchtime, not that a model approved it.

Reporting is safe more often than teams expect. A weekly report that will eventually be generated live can be assembled by a script and emailed. If the report turns out to be the product, you will find out, and you will have lost nothing building the live version of the wrong report.

Notifications and nudges are safe. Sending them on a schedule rather than on an event is usually indistinguishable to the person receiving them, and event driven delivery is a meaningful amount of infrastructure.

Integrations are safe surprisingly often. A nightly export and import tells you whether anybody uses the integration at all, which is the thing you actually need to know before building a real sync with conflict handling.

What you must not fake

Anything that becomes a lie if it is wrong, and anything the system will be shaped around forever.

Money is the first. If the product takes a payment, that path has to be real from day one. A manual workaround around money produces reconciliation problems that outlive the version that caused them, and it damages trust in a way features cannot repair.

Anything regulated is second. Consent, retention, access controls, audit trails. These are not features you add later. They are properties of how data moves through the system, and retrofitting them means rewriting the paths you built around their absence.

Your core data model is third, and this is the one teams get wrong most often. You can fake almost any behaviour, but the shape of your central entities will be inherited by everything built afterwards. If you are not sure whether a booking belongs to a person or an organisation, that question deserves a real answer now, because every table, screen and permission check downstream will encode whichever answer you picked by accident.

Finally, anything where the fake is visible. If a user can tell that a response took four hours because somebody did it by hand, and they expected it to be instant, you have not faked the feature. You have shipped a worse one.

The rule that makes this work

Write down every fake, with the condition that ends it.

Not a vague intention to automate later. A number. The manual matching ends at forty matches a day. The nightly sync becomes live when a customer asks for same day. The spreadsheet becomes a table when two people need it at once.

Without the condition, fakes become permanent by default, and in eighteen months somebody discovers the business is being run from a spreadsheet nobody wants to own. With the condition, each fake is a decision with an expiry date, and the person running it knows when to raise their hand.

This single list is the difference between a disciplined first version and technical debt with a nice story attached.

Why this matters more than cutting scope

Cutting scope removes something a user wanted. Faking keeps it and defers the cost. The user sees the complete product. You see a much smaller build.

It also changes what you learn. A feature that was cut teaches you nothing. A feature that was faked teaches you exactly how often it is used, by whom, and what people actually expect it to do, which is the information you need before writing the real version. Half the fakes in a typical first version turn out never to need automating at all, because usage was lower than anyone predicted.

That is not a failure of the forecast. That is the point. You bought that information for the price of a spreadsheet instead of a sprint.

Where this fits in practice

This approach suits MVP Development Services particularly well, because the pressure in a first version is always to show something complete to someone who is deciding whether to fund the next stage. Faking lets the demo be honest and complete at the same time.

It applies the same way whether the work ships on iOS, Android, React Native or Flutter, since almost every fake lives behind the interface rather than in it. It applies to AI Solutions and AI App Solutions with extra force, because the manual version of an automated judgement is also your training data and your evaluation set, and teams that skip it end up building a model with nothing to measure it against.

It applies least in Digital Transformation and Product Engineering work inside large organisations, where the manual step often cannot exist for compliance reasons. Even there the list is useful, because it makes explicit which parts genuinely cannot be deferred rather than leaving it to argument.

The uncomfortable part

Somebody has to do the manual work, and that somebody is usually a founder or an early employee who has better things to do. This is a real cost and it should be counted. If the fake takes two hours a day and will run for four months, that is a significant amount of somebody's time.

Count it anyway, and compare it against what building the real version would have cost before you knew whether anyone wanted it. In most first versions the comparison is not close.

Build the things that would be lies if they were fake. Fake the rest, write down when each fake expires, and go find out which ones never needed building.