Your MVP Does Not Have To Be Perfect. The Foundation Does.
Two camps are shouting past each other right now. One says vibe-coding means anyone can ship a product and the technical co-founder is obsolete. The other says AI-assisted code is a disaster waiting to happen and any system built this way will collapse. Both are wrong in the same way. They are not asking the right question.
The question is not whether AI-assisted development works. I use it daily, in production. It works. The question is what it works for, and what it does not work for. That is the same question that has always sat under "what belongs in an MVP". The new tools have made it more urgent, not different.
There is a difference between scope and foundation that founders tend to learn the slow way. Scope is what your product does. Foundation is what your product is built on. You can change scope every quarter without much pain. You cannot change foundation without rewriting half the system.
The early-stage advice "do not polish" applies to scope. It does not apply to foundation. Mixing those up is the expensive mistake. Vibe-coding makes that mistake easier to walk into, because it produces things that look like products before they are.
Scope can stay small. The kernel has to be solid.
Keeping scope small does not mean shipping something rough. It means doing fewer things, and doing them properly.
The early product should have one job, or two. Not five. Whatever those one or two things are, they need to work cleanly. Easy to put data in. Easy to get the right output back out. A user should be able to do the one thing the product does without surprises. The kernel is not allowed to be sloppy. The number of things the kernel does is allowed to be very small.
That is the difference between an MVP and a prototype. A prototype proves the idea works for someone in a demo. An MVP does the one real job, every time, for the first paying user.
This is exactly where vibe-coding earns its place. Making an idea tangible, testing whether a hypothesis holds, letting a founder explore the solution space without waiting for a developer, building a small internal tool — these are real uses, and they are better done now than they ever were. A founder who can put a working prototype in front of a customer in a week is in a stronger position than one who needs three months and a budget.
The mistake is assuming the prototype is the product.
Foundation is the part nobody asks for
While the scope is small and the kernel is clean, there is another layer of work that gets done quietly. None of it shows up in a demo. None of it is on the feature list. None of it makes the next sales call land better. But each piece carries an asymmetric cost: cheap to do on day one, expensive to retrofit on day three hundred.
- Version control and a deployment pipeline. Code in a folder on someone's laptop is not a product. It is a science project. Without git, code review, and an automated way to ship to production, there is no foundation for a second person to join.
- The data model. How you structure what you store. The relationships between users, accounts, orders, events. This is the thing you will live with for a decade. Schema changes are painful and risky. Once data is in the wrong shape, every later decision works around that shape.
- Separation between layers. Keeping the database, the business logic, and the interface in clearly separate parts of the code. It sounds bureaucratic in month two. It is what makes month thirty-six even possible.
- Logging and error handling. Knowing what your system is doing when it runs, and what happens when something goes wrong. Without it you cannot debug, you cannot improve, you cannot trust the numbers.
- Security and the boring legal layer. Authentication that holds up. Secrets that are not in the repository. Inputs that are validated. GDPR handled before the first real user signs up, not after.
A vibe-coded prototype almost never has these. Not because the tools are bad, but because nobody asked for them. You prompt for the feature you can see. You do not prompt for the migration story you have not yet needed. The AI fills in plausible code where careful design was required, and the result feels finished long before it actually is.
A founder showing this product to an investor will not mention any of it. That is fine. But if it is missing in the first months, the cost only shows up later, and by then it is the kind of cost that takes a year to pay off.
What this looked like in practice
When I joined DirectorInsight, we had zero clients. A CEO with a vision, a front-end developer, a mathematician, and me. The product would let investors and HR teams compare executive compensation against company performance across listed companies.
The scope of the first version was narrow on purpose. Two things, and only two things: compensation per person, and performance per company. Put both in, get both out, cleanly. AEX-listed companies first. Nothing else.
But "narrow" did not mean "rough". Those two things had to work properly. The data had to be easy to enter, easy to verify, easy to display. The first dashboards were not pretty afterthoughts. They were thought through. Small, but right.
The mathematician had worked out the analysis logic in Excel. The peer group comparisons, the pay-for-performance screens, all of it ran inside his spreadsheets. My job was to translate that into a normalised relational schema in the database, so the same logic could run on a thousand companies instead of twenty, on five years of history instead of one, without falling over.
That translation was where time got spent. A schema that captures compensation per person and performance per company in a way that lets you query them together across years and across markets, that does not collapse when you add a new index next quarter — that is not something you build in an afternoon. And it is not something an AI assistant builds for you without someone driving who knows what to ask of it.
What we shipped first was small. AEX, two core concepts, the cleanest version of those two concepts we could build. Later, we added depth: more ways to slice the same data, board composition, talent identification, derived analyses. We added breadth: the rest of Europe, then the United States, then Japan.
None of those additions required rebuilding the kernel. The schema absorbed them. The pipeline shipped them. The separation of layers meant that adding a new view did not break an old one.
When Broadridge invested, and later when the product was acquired by Diligent, what they were buying was not the breadth or the prettiness. It was a product whose foundation could carry whatever the next phase asked of it. The first months of careful schema work made the next ten years possible.
Where this leaves the vibe-coding debate
The two loud positions are both wrong. Vibe-coding is not going to replace serious engineering. Serious engineering is not going to ignore AI-assisted development out of existence. We are in a transition, and most people are still figuring out which tasks belong on which side of the line. I am too. The honest answer changes month by month.
What does not change is the scope-versus-foundation distinction. Vibe-coding is excellent for scope work: trying things, proving the idea, making something tangible, exploring what your product wants to be. It is much weaker on foundation work: data models, schema evolution, security, the engineering that has to keep holding up while the scope grows around it. Not because the tools fail at it, but because the questions you need to ask are not the ones a non-technical founder knows to ask.
That is the gap a non-technical founder runs into. The prototype works. The demo lands. The first user signs up. And then somewhere between user fifty and user five hundred, something starts to bend. The data is in a shape that does not quite fit. A feature that should be straightforward turns out to require changes in twelve places. A bug in production cannot be traced because nothing is logged. Each of these has the same root cause: the foundation was never built, because nobody asked for it.
Vibe-code your prototype. Test your idea. Show your customer. That is real value. Just do not confuse the moment the prototype works with the moment you have a product. The first months of careful, boring, invisible work — the choices nobody sees — are still where the durable products come from. That has not changed, and I do not think it is about to.
The MVPs that scale are not the ones with the prettiest first version, or the ones built fastest by the cleverest tools. They are the ones with the boring choices made carefully on day one.
Kort samengevat: er zijn nu twee kampen die langs elkaar heen schreeuwen. Het ene zegt dat vibe-coding betekent dat iedereen een product kan bouwen en de technische man overbodig is. Het andere zegt dat AI-augmented code altijd tot een ramp leidt. Allebei niet realistisch. Ik gebruik AI-augmented development zelf dagelijks in productie. We zitten in een transitie, en de echte vraag is niet of het werkt, maar waarvoor. Vibe-coding is uitstekend om ideeën tastbaar te maken, hypotheses te testen, de oplossingsruimte te verkennen. Daar wint het. Maar het bouwt geen datamodel dat tien jaar meegaat, geen migratiepad, geen versiebeheer en geen serieuze foutafhandeling. Dat onderscheid is hetzelfde als het oude scope-versus-fundering verhaal. Scope mag klein, maar wel goed. Fundering moet diep, ook al ziet niemand het. Bij DirectorInsight begonnen we met twee dingen: compensatie per persoon en performance per bedrijf, eerst alleen AEX. Onze wiskundige had de logica in Excel uitgewerkt, ik vertaalde dat naar een genormaliseerd schema in de database. Het eerste dashboard was niet ruw, het was klein en goed. Later kwamen de verdiepingen en de andere markten erbij, zonder dat de kern eraan moest. Toen het platform werd overgenomen, was het de fundering die dat mogelijk maakte. Vibe-code je prototype gerust. Verwar het alleen niet met een product.
Jan Keijzer is owner of Imperial Automation and a freelance Senior Software Engineer. He builds products from zero for founders who have an idea but no technical partner. Python, FastAPI, LLM workflows, AI-augmented development. PhD Reactor Physics, TU Delft.