Why Your AI-Built App Does Ten Things and None of Them Work

You opened the tool, typed your idea, and watched something appear on screen. It was rough, but it was real: a login page, a dashboard, maybe a form that actually submitted. So you kept going. One more feature. Then another. Three hours later you had something that looked like a product. Two days later it stopped working, and you could not tell which prompt broke it.

This is not a story about a bad tool. It is a story about a build with no boundaries.

The AI Does Not Know What Your Product Is

When you prompt an AI coding tool, you are giving it an instruction, not a brief. The tool has no concept of your product's purpose, its intended user, or the one thing it needs to do well. It has the contents of your current message and whatever context remains from earlier in the session. That is everything it knows.

This matters because scope, the decision about what a product does and does not do, is entirely your responsibility. The tool has no mechanism for saying "that feature is outside the scope of what you are building." It will build whatever you ask for with equal willingness. A login system. A notification centre. An admin panel. A reporting dashboard. Each one arrives looking functional. None of them are integrated into a coherent product, because you never defined what a coherent product looked like before you started building.

The result is a prototype that does ten things and none of them well. Not because the individual pieces are badly built, but because there was no architectural intention governing how they connect, or whether they should connect at all.

Why Founders Are Particularly Vulnerable to This

If you come from a product, marketing, or operations background, you are trained to think in features. Your mental model of a product is a list of capabilities: users can log in, users can upload files, users can invite teammates, users can see a dashboard. That list is how you describe value. It is also, when handed directly to an AI coding tool without translation, a scope disaster.

Each item on that list is a feature. Each feature has dependencies, edge cases, data requirements, and interactions with every other feature. A login system alone, properly implemented, involves session management, password hashing, token expiry, reset flows, and device handling. When you prompt for it casually alongside five other features, you get a version of each that was built without accounting for the others. The login system does not know about the dashboard. The dashboard does not know about the file uploads. The notification centre is wired to nothing.

This is not a capability failure. The tool built exactly what you asked for. The failure is that you asked for a product list when you needed to ask for one thing done completely.

The Scope Boundary Test

Before you write a single prompt, you need to be able to answer one question with a single sentence: what is the one thing this product does for the user, from the moment they arrive to the moment they get value?

Not a list. One sentence. One flow.

If the answer requires more than one sentence, your scope is already too large. That is not a subjective judgment; it is a structural signal. A product that cannot be described in a single user journey sentence has not been defined yet. It has been imagined.

Here is what that looks like in practice. A founder building a client onboarding tool might describe their product as: "A client receives a link, fills in a form, and the founder receives a summary email." That is one flow. One value exchange. That is something you can build, test, and validate without a login system, a dashboard, or a notification centre, none of which are required to test whether the core value works.

The login system comes later. The dashboard comes after you have proven the core flow is something users actually need. The notification centre comes when users are asking for it. None of them belong in Version 1.

Imposing Scope Discipline on a Prompt Session

Once you have your single-sentence scope definition, your job during a build session is to enforce it. Every prompt you write should be evaluated against one criterion: does this prompt build or extend the core flow, or does it add something outside it?

This sounds obvious. It is not how most people build. The natural tendency during a session is to add. You get the form working and immediately think about what happens when someone submits duplicate data. You get the email sending and immediately think about whether the founder should be able to customise it. Each of these is a reasonable thought. Each of them is also scope expansion, and every scope expansion during a build session is a gamble on whether the new addition will break what already works.

The discipline is to log these additions, not act on them. Keep a running list (call it a backlog, a parking lot, whatever you prefer) of every feature idea that occurs to you during a build session. Write it down. Do not prompt for it. When the core flow is complete and working, evaluate the list. Some items will still seem important. Many will not. A few will require fundamental architectural changes to implement cleanly. You want to know that before you have already built on top of a structure that cannot support them.

This is how scope discipline works in traditional software development. There is a defined scope. There is a process for capturing scope expansion requests. There is a deliberate decision about what gets built in what order. The process exists because without it, projects fail, not because developers lack skill, but because complexity compounds faster than any individual can manage reactively.

Vibe coding has no built-in version of that process. You have to impose it yourself, before the session starts, because the tool will not impose it for you.

What You Are Actually Testing

The other reason scope discipline matters in the early stages is that your prototype is not a product; it is a test. The question it needs to answer is not "can I build this?" but "does anyone want this?" Those are different questions, and they require different builds.

To answer the first question, you need a working implementation of every feature. To answer the second, you need a working implementation of the core value exchange, the one thing your product does that makes someone say "yes, I need this." Everything else is infrastructure for a product that has not yet proven it deserves to exist.

An MVP built for validation is not a small version of the full product. It is a focused test of one hypothesis. If your hypothesis is that founders need a faster way to onboard clients, your test is the onboarding flow. Not the login system. Not the dashboard. Not the team management features. The onboarding flow, working well enough that a real user can complete it and you can observe whether it solves their problem.

AI makes it easy to build more than you need. That is not a feature; it is a trap. The speed of AI-assisted building removes the natural friction that previously forced scope discipline. When a feature used to take a developer three days, you thought carefully about whether it was worth building. When a feature takes a prompt, you add it without thinking. The result is a prototype that reflects every idea you had during a build session rather than a focused test of your core hypothesis.

The scope boundary test, the single-sentence definition, the backlog discipline: these are not bureaucratic overhead. They are the thinking layer that makes AI-assisted building produce something useful instead of something complex.

Before You Open the Tool Next Time

Define the scope before you open anything. Write one sentence describing the core user flow. Test it: can a user complete this flow and receive value without any of the features you are considering adding? If yes, those features are not in scope for Version 1.

Write down every other feature idea you have. Put them somewhere you can find them. They are not gone; they are deferred until the core is proven.

Then build only what the sentence describes. When an idea occurs to you during the session, add it to the list. Do not prompt for it.

If the build session produces a working version of the core flow, you have succeeded. You have something you can put in front of a real user and learn from. Everything else is a distraction from that test.

The MVP Scoping Template gives you a one-page framework for running this process before you start any build session. It covers scope definition, core flow mapping, and a structured backlog format. Download it before your next session.