You Shipped an MVP With AI. Six Things Break Next.

Building a working product without a development team is now genuinely possible. That is not a marketing claim — I have taken over several of these systems and the working parts work.

But there is a consistent pattern in what fails afterwards, and it is worth knowing before real users and real data arrive rather than after. The failures are not random, and they are not really about code quality. They are about the questions nobody thought to ask, because the thing appeared to be finished.

Here they are, roughly in order of how expensive they are to discover late.

1. Authorization

This is the one that matters, and it is worth more attention than the other five combined.

Authorization is the rule about who is allowed to see and change which records. The failure mode is that the rule is enforced in the interface — the app shows customer A only their own records — rather than in the database, which would refuse to return customer B's records at all.

The difference does not show up in normal use, because in normal use people click the buttons you gave them. It shows up when someone changes a number in a web address, or when a page loads in an unexpected order, or when anything is accessed outside the path you designed.

You can test this yourself in ten minutes and you should do it today. Create two accounts belonging to two different customers. Log in as the first, open a record, and look at the address bar for an identifier. Change it to a record belonging to the second, and reload.

If you see the other customer's data, stop adding features. Nothing else on this list is as urgent, because it is the failure that does not stay an internal problem — it becomes a disclosure, and in some industries a reportable one.

2. Sessions and password reset

Logging in usually works, because it is the part that gets tested constantly during building.

What gets tested rarely: what happens when someone stays logged in for three weeks, whether logging out on one device affects the others, whether a password reset link can be used twice, whether it expires at all, and what happens when someone requests a reset for an email that is not registered.

These are unglamorous and they are where account takeovers actually come from — much more often than anything sophisticated.

3. The data model, once there is more than one customer

Most AI-assisted builds are shaped around one example customer, because that is how the conversation went while building it.

Then the second customer arrives with a slightly different process, and the reasonable-looking fix is an extra field. Then a third arrives and it is another field, or a text column holding a list of things, or a special case in the code for one client name.

Six months later, a straightforward request — a report grouped by something new, or a customer wanting their own naming for a status — turns out to be a rebuild. Nothing broke. The shape just stopped fitting, and it stopped fitting gradually enough that there was no moment to notice.

4. Migrations

A migration is how you change the structure of a live database without losing what is in it.

If your current process for changing the database is to open a console and make the change by hand, then you have no record of what changed, no way to apply the same change consistently, and no way back if it goes wrong. That is survivable while you are the only user. It stops being survivable the first time a change has to happen while people are working.

This one is invisible until the day it is catastrophic, which is why it rarely gets attention in advance.

5. Secrets

Keys for payment processing, email, storage, and any other service you connect to.

The common failure is that they end up committed into the code repository. Once there, they are in the history permanently — removing the line later does not remove it from the record, and a private repository is one accidental setting away from not being private.

Rotating a key is fifteen minutes. Discovering that a payment key has been public for eight months is a different kind of day.

6. No tests around the money path

I am not going to argue for comprehensive test coverage on an early product. That is a real debate with real trade-offs and it is not the point here.

But there is usually one path where an error costs actual money or actual trust: charging a card, issuing a refund, calculating an invoice, applying a discount, sending something to a customer. That path deserves an automatic check that runs before anything ships, because it is the one place where a small regression is not a small problem.

Everything else can be tested by using it.

The counter-advice

The instinct after reading a list like this is to stop and fix all six before launching.

That is usually the wrong call. Item one is genuinely urgent and worth delaying for. Items three through six are worth doing before you have significant numbers of customers, not before you have your first — and a product that never launches has a failure rate of one hundred percent, which is worse than any of these.

The useful version is: fix authorization now, know about the other five, and address them in the order above as real usage arrives. Knowing what is fragile changes how you behave even before you fix it.

Why this list is so consistent

Building software with AI compresses the part that used to be slow — producing something that works — and leaves untouched the part that was always the hard part: deciding what should be true about the system when things go wrong.

That was never really a coding problem. It was a judgment problem, and it is the reason the same six items appear in almost every system I am asked to look at, regardless of what built it.

If you want to check your own, start with the ten-minute test in section one. It is the only item where finding out late means finding out from someone else.

Related reading: If Your Only Developer Quit Tomorrow · Nobody Is Reviewing Your Developer

---

If you would rather have someone else run all six checks, a fixed-scope review of an AI-built app is one of the most common first projects I take on - book a 30-minute call.