The most useful skill in building an MVP is not building fast. It is knowing what to fake. Find the one part of the product that carries your entire argument, build that part for real to a standard that survives messy input, and stub everything else until it has to exist. Founders who skip this build a small version of everything, which is still everything, and they run out of time and money before they have proven a single thing.
This is the practical heart of building to prove an idea, so let me be specific about how the call actually gets made, because “just build less” is useless advice without a way to decide what less means.
What does “fake it” actually mean?
Faking a part of the product means building it as a stub rather than the real thing: static data instead of a live feed, a screen that looks finished but is not wired to real logic, a step a human does quietly by hand instead of an automated pipeline. The user sees something that behaves the way they expect. Behind it, the machinery is not real yet, because it does not need to be to answer the question you are actually asking.
This is ordinary, respectable product practice, not a trick. One of the most successful early online marketplaces processed its first orders by hand, behind a storefront that looked fully automated, to find out whether anyone wanted to shop that way at all before building the automation to do it at scale. They faked the plumbing to test the demand. That is exactly the move, and it saved them from building an expensive engine for a car nobody had proven they wanted to drive. The faking bought them the one thing that mattered: a real answer, early, for almost nothing.
Where is the line between faking and lying?
There is a hard line here, and it matters more than any other rule in this piece. Faking the internal machinery to test whether people want the outcome is fine. Faking the outcome itself, the results, the evidence, the proof, is not, ever, whether the audience is a user or an investor.
Processing an order by hand while the front end looks automated is faking the plumbing, and it is honest, because the user genuinely gets what they came for. The experience they were promised is real. Showing an investor a metric that is not real, or a user a result the system did not actually produce, is faking the proof, and it is a lie that will cost you far more than it ever saves, because the entire point of this exercise is to gather true signal, and a faked result poisons exactly that. The test is simple. Fake how the outcome is delivered while you learn. Never fake whether the outcome is real. Everything else in this piece is about the first kind, and nothing in it excuses the second.
How do you find the one part to build for real?
Find the part that carries the argument. Every idea has one feature, one moment, that is the actual bet. If it works, people believe. If it fails, the idea sinks, no matter how polished everything around it is. That is the part you build for real, and you build it to a standard that survives real, messy input rather than a clean demo script that you control.
Ask yourself which single thing, if a skeptical user experienced it working on their own data, would move them from “interesting” to “I need this.” That is your ten percent. On a product I scoped this way, it came down to a single screen, the one that carried the whole promise of the product. I built that screen properly, wired to real logic, able to handle input I did not plan for and would not have thought to test, and I stubbed everything leading to it and away from it with static data that looked real enough for the moment. The onboarding was a shell. The account settings barely worked. But the one real screen was the entire argument, and it had to be undeniable to the exact person I was trying to convince.
A useful way to pressure-test your choice: imagine you are only allowed to show a prospect one screen, for thirty seconds, with no explanation. Which screen do you show? That is the one to build for real. Almost everything else can wait.
What is safe to fake, and what is not?
Safe to fake are the supporting cast: onboarding flows, settings, secondary features, admin tooling, billing you will need eventually but not to prove the core, and anything a user merely passes through rather than comes for. These can be thin, stubbed, or done manually behind the scenes without weakening your proof at all, because nobody decides whether they want your product based on how nice the settings page is.
Not safe to fake is the core experience itself, and anything you present as evidence. If the thing you are proving is that your AI gives reliable answers, then the answers have to be real, and they have to hold up under a skeptical user’s worst input, because that is the whole claim you are making. You cannot stub the exact thing you are asking people to believe in. This is why reliability and evaluation are not optional even in a scoped build, a point I make in can you build a real product with AI without a dev team. The real part has to be genuinely real, or you have proven nothing and only convinced yourself.
How AI shifts the build-versus-fake line
AI-native development changes the maths of this decision, though not the principle underneath it. Some things that used to be clear candidates to fake, because building them for real was slow and costly, are now cheap enough to just build properly the first time. The line between what is worth faking and what is worth building has moved, and it keeps moving as the tools improve, so it is worth re-drawing for each project rather than reusing last year’s instinct.
But the discipline underneath does not change. You still build what proves the idea and stub what does not, because time and attention are finite even when code is cheap, and a product bloated with real-but-pointless features is still a product that took too long to reach its first real user. And the hard line holds regardless of how good the tools get: fake the plumbing to learn, never the evidence. This scoping judgment is what makes the whole approach in build the product before you build the team actually work in practice, instead of collapsing back into building everything.
If you want help finding the one part of your idea that carries the argument, and deciding what to build versus fake, that is a large part of what we do at ThinkShift. Tell us what you are building using the form on our contact page, and we will help you scope it to exactly what proves it. You can also see how we have applied this to our own products.
Written by Imran Baig, founder of ThinkShift. ThinkShift builds your product with AI so you can prove it before you build the team. More at imranbaig.io.
Common questions
What does it mean to fake part of a product?
It means building the parts that do not carry your core argument as stubs: static data, a manual step behind the scenes, a screen that looks finished but is not wired to real logic yet. You fake the supporting cast so you can build the one part that proves your idea to a real standard, and you replace the fakes only when they have to exist.
Isn't faking parts of the product dishonest?
There is a clear line. Faking internal machinery to test whether people want the outcome is normal product practice, a famous early marketplace processed orders by hand behind the scenes. Faking results, evidence, or claims to a user or investor is not, and it is never acceptable. Fake the plumbing, never the proof.
How do I decide what to build for real?
Find the one thing that carries your argument: the feature or moment that, if it works, makes people believe, and if it fails, sinks the idea. Build that for real to a standard that survives messy input. Everything else is a candidate to fake until it earns its place.
Does AI change what I should build versus fake?
It changes the balance. Because AI-native development makes real builds much cheaper, some things that used to be worth faking are now cheap enough to build properly. But the core discipline holds: build what proves the idea, stub the rest, and never fake the evidence itself.
ThinkShift builds your product with AI so you can prove it before you build the team.
Let's talk