Founders come to us with a build already fully formed in their heads. They have the screens, the flows, sometimes a name and a logo, and what they want from a studio is execution: turn the picture into a working product. It is a reasonable ask, and it is the one we are set up to say yes to. But the most valuable thing we can do in a first conversation is not always to agree. Roughly half the founders who arrive asking for an MVP would be better served by a week of validation than by a codebase, and telling them so is part of the job. The fastest way to waste a first build is to build it before you know it is the right thing to build.
An MVP is a way to learn, not a way to launch
The phrase minimum viable product has drifted over the years into meaning a small first version of the real thing. That is not what it is for. An MVP is an experiment. Its output is not a product, it is an answer to a question the founder cannot yet answer any other way: will the people I think have this problem change their behavior to use what I make. If you already know the answer, you do not need an MVP, you need the actual product. If you do not know the answer, then the MVP has to be designed around the question, and most of the ones we are handed are not. They are designed around the founder's vision of the finished thing, which is a different and much more expensive object.
The test we run before writing any code
Before we scope a build, we try to answer three things with the founder, and none of them requires a repository. First, what is the single riskiest assumption this whole idea rests on. Second, what is the cheapest way to find out if that assumption is true. Third, what specifically would have to happen for us to decide it is false. If the riskiest assumption is that people want the thing at all, code is almost never the cheapest test, and writing it first means spending the most money to learn the thing you could have learned for the least. If the riskiest assumption is technical, that something can actually be built or made fast enough or accurate enough, then a narrow build is exactly right, and we scope it to that one question and nothing else.
The signals that mean stop, not go
A few patterns come up often enough that we treat them as a reason to slow down. When a founder cannot name a single specific person, by name, who has the problem and would pay to have it solved, the idea is still an abstraction and a build will only make the abstraction more elaborate. When the feature list has grown before anyone has talked to a user, the scope is being driven by imagination rather than evidence. And when the honest reason to build now is that building feels like progress and talking to customers feels like exposure, that is the most important signal of all, because it is the one founders are least likely to say out loud. A codebase is a very comfortable place to hide from the question of whether anyone wants what you are making.
What a week of validation actually looks like
Validation has a reputation for being vague, so we keep it concrete. It is usually a week, sometimes two. It means a dozen real conversations with people who have the problem, structured to learn rather than to sell. It often means a landing page that describes the offer as if it existed and a small amount of spend to see whether anyone clicks, signs up, or replies. Sometimes it means a founder manually doing, by hand and badly, the thing the software is eventually supposed to automate, to see if the outcome is even wanted before the machine that produces it gets built. The deliverable is not a product. It is a decision made on evidence instead of hope, and it costs a fraction of a build.
When the answer is genuinely build now
None of this is an argument against building. Plenty of the founders we talk to have already done the hard part. They have the specific customer, they have the demand, and the only real unknown left is whether the thing can be made well and fast. For them, delay is the mistake, and the right move is to compress the build the way we describe in from idea to MVP in weeks and get a real product in front of real users quickly. The point is not to be slow. It is to make sure the speed is pointed at a validated target, so the weeks you spend building are spent on the version of the product the evidence actually supports.
Saying no is what makes the yes worth anything
A studio that will build anything you describe is not doing you a favor. It is selling you certainty it does not have and charging you for the privilege of finding out later. We would rather be the ones who ask the uncomfortable question early, when it is cheap to change course, than the ones who cash the check and hand over a beautifully built answer to a question nobody asked. That discipline is the same operating principle we bring to everything we ship, and it is why how we approach MVP development starts with the decision of whether to build at all. If you are weighing a first build, tell us what you are trying to prove and we will be honest about whether code is the right way to prove it.