Starting small in the age of AI, without overloading yourself

What an MVP really is

The three letters MVP send many people down the wrong track, the arithmetic of "product minus half the features". By that logic you simply build less and call the result a minimum viable product. The decisive part sits not in the word "minimum", though, but in "viable": the point is not to build as little as possible, but to build the smallest version that answers a real question, namely whether anyone wants the problem solved at all and whether your solution is any good for it.

This difference decides what you build first, and it separates two things that look alike easily. A pretty mock-up nobody seriously uses is not an MVP, even if it is small, because it answers nothing. Conversely, the half product with ten features is not one either, because it builds a lot before it even knows whether the direction is right. The right smallest version is the one that clears the most important open question with the least effort, and everything else may wait.

An example makes that tangible. Say you want to build an app that helps small trade businesses write their quotes faster. The most important open question is not whether you can pull off a pretty interface, but whether a tradesperson would rather send a quote written this way than their current one. The MVP for that can be a single form that turns a few inputs into a finished PDF, no login, no template management, no invoicing module. Once the first real tradesperson sends a real quote to a real customer with it, you have learned more than from any glossy demo.

And here comes a thought most people find hard: if the answer is "no", you are allowed to throw away what you built, and with no bad conscience. People used to resist that, because every prototype held weeks of work you did not want to bin. But the same AI that made building cheap has also made throwing away cheap. An MVP that delivers an honest "no" has fully served its purpose, because it spared you an expensive dead end. The value sits in the answer, not in the code, and whoever internalises that dares to ask the questions that really matter.

Why AI in particular makes starting small possible

Starting small was always good advice, but for a long time also hard advice. Whoever wanted to build the quoting app from the example used to face weeks of work before even the first form ran: set up a development environment, frame a skeleton, connect a database, get the PDF generation working. The actual question, whether the tradesperson likes the thing, came only after all that groundwork.

This is exactly where the situation has shifted. AI-assisted tools now take a large part of that mechanical work off your hands, from the first scaffold of an interface through connecting a database to the many small pieces you used to have to write line by line yourself. What took weeks shrinks to hours, and the long groundwork that smothered so many ideas before they started falls away in large part.

The new technology thus shifts not only the pace, but also who can start at all. A founder with a clear idea but without a large development team gets further today than ever before, because the assistant handles the first implementation and she can concentrate on the actual question, namely whether the product is useful to anyone.

Two things should not be confused here, though. The fast first thing is a tool for learning, not a finished product. AI gets you to something runnable in hours, but it does not make the decision which question your MVP is meant to answer, and it does not take responsibility for the thing running safely and reliably later, once real customers count on it. The easier building gets, the more important therefore the mind that decides what should be built and what not. Exactly this shift, away from plain coding towards judgement, runs through everything that follows.

Why the nearly finished thing suddenly feels sticky

After the fast start almost everyone goes through the same thing. The thing runs, the demo convinces, it feels like ninety percent done. Then weeks pass, and the last ten percent just will not fall. That feeling is no sign you are doing something wrong, but the result of an illusion that lies in the nature of the matter.

AI delivers in a flash exactly the part that was always the easier one: the visible surface, the happy path, the pretty demo. The hard part was never the demo, but everything that comes after: the user who types in something unexpected, the two things that go wrong at once, the case nobody thought of. That work has not vanished, it only became more visible, because the easy part is now gone so quickly. Whoever knows this stops measuring progress by the demo and does not panic when the second half takes longer than the first.

You need not write every line, but answer for it

The second stumbling block is quieter and more dangerous. An AI assistant produces code that runs, and it is tempting to just take it as long as the result is right. For an MVP that is perfectly fine. But as soon as real users count on it, every part nobody on the team truly understands turns into a silent debt. When something breaks, you cannot place it. When something should change, nobody dares touch it. And "ask the AI again" only carries as far as someone can judge the answer.

That "it runs" does not mean "it is secure" now shows in the numbers. One analysis of real-world codebases found that AI-assisted teams shipped roughly four times faster, but built in about ten times as many security flaws (IBM, 2026). An academic study that formally checked 3,500 code artifacts generated by seven language models reached a similar picture: 55.8 percent contained at least one provable vulnerability (arXiv, 2026). That does not mean a human is the better programmer or reviewer, AI is often excellent at both. It means that deciding whether a solution is the right one takes both at once: an understanding of the code and an understanding of the business problem it is meant to solve. Only someone who sees both sides can judge whether what is running also does the right thing.

The line therefore runs not between "write it yourself" and "let AI write it", but between "I understand what is running and what for" and "I hope it fits". You need not type every line yourself, but you have to be able to answer for every line, meaning to know what it does, why it is there and what happens when it fails. That is exactly the difference between a prototype that impresses and a product you run with a clear conscience, and it is also why the judgement to think code and business problem together grows more important in the age of AI, not less.

Two parts imagined, six fields built

When starting quickly, you usually think of a product in two parts: the interface the users work with at the front, and the logic that stores and processes data at the back. Frontend and backend, that is the mental model most people start with, and as an entry point that is entirely right.

But as soon as the thing gets real users, real data and real operations, it turns out that behind the two imagined parts lies a whole row of further topics. Users have to log in, data has to be stored securely and in line with data protection, the application has to run reliably, errors have to surface, and at some point the question arises how a new release goes live without risk.

These topics map onto the six fields we think in anyway, the same ones our mixer on the home page arranges: tempo, AI, cost, reliability, security and governance. At the start it is enough to get far on a few of these axes, namely where frontend and logic sit. Over time the product grows outward on all axes, and that growing area is the learning journey. Why this ability, to build and run software yourself, is worth it right now and not just for products but for your own business processes, we describe in the article The logical consequence of the SaaS moat disappearing.

These topics do not appear right at the start, but one after another, each time the product moves a step further. That is exactly why it is wise to start small early and to build out a field only when it really knocks, instead of trying to serve all six at once at the start.

The load that grows with the product

With every new field you build out comes not only technical work, but also a set of questions that were not there before. Legal matters knock, from the privacy policy through the site notice to the question of how you may handle user data. Design becomes more important, because a product that has real users also has to be understandable and accessible. And the technical questions get deeper, from secure login through deployment to monitoring.

This sum of topics creates a load you do not see on day one, and that feels crushing when you take it as a heap that all wants doing at the same time. In fact no field arrives before it is needed. You need a privacy policy once real user data flows, a proper deployment once others rely on the running version, monitoring once an outage hurts someone. Whoever sees that has no wall in front of them, but a sequence, and in a sequence you only ever need to know the next step.

Whoever builds alone carries every field

But there is a point at which the learning journey tips over, and it has less to do with technology than with the person who carries it all. Whoever builds alone spreads the same limited time and attention across more and more fields. At the start this works, because only a few fields are open and you learn quickly. But the more fields become active, the thinner each slice gets, and from a certain point the load grows faster than your own progress keeps up.

Looking after yourself is therefore not a soft extra, but a sober operational question, especially when you build alone. It is not about wellness, but about the fact that a single overloaded person is the biggest risk to the young product. Breaks, clear boundaries between the project and the rest of life, and someone to share decisions with are what make the difference between holding on and burning out.

This is exactly where our guidance comes in, and concretely so. We look at your product with you and tell you which of the six fields is next and which you can leave alone with a clear conscience, so you do not burn time in the wrong place out of uncertainty. When a field comes up that you do not know yet, such as the first clean login or a deployment that does not make you flinch at every release, we show you the way instead of walking it for you.

The difference from a classic agency is that in the end you can do it, not us. We are the extra mind that carries the load while it is too big for one, and that makes itself redundant once you carry the field yourself. Your product, your decisions, your knowledge stay with you. That is the difference between guidance and dependence.