Before that moment, a broken flow costs you an afternoon. After it, the same broken flow costs you a refund, an apology, or a customer who quietly leaves. The thing you built hasn’t changed. What it is allowed to get wrong has.

Your prototype works. That’s not in question, and it’s why you have customers. The gap is everything that happens once it isn’t only you using it. The usual order in which it breaks is predictable, and each break has a check you can run today. You don’t need to be an engineer to run them.

Check 1: Can you get your data back after a bad day?

What to look at. Where does your customers’ information actually live? In a spreadsheet, a no-code database, an automation tool’s internal storage? Now ask: if someone deleted it this afternoon, by mistake, yours or theirs, how long until it’s back, and from what?

A bad answer. “I think the platform keeps backups.” Or: “I could probably export it.” Nobody has ever tested that sentence. The usual version of this story is a well-meaning edit, a bulk delete, or an automation that overwrites a column, and a founder discovering that the platform’s “history” only goes back a few days, or doesn’t cover that kind of change.

What to do. Make a copy of everything that matters on a schedule, store it somewhere separate from the tool itself, and restore one copy once to prove it works. A backup you’ve never restored is a hope, not a backup.

Check 2: Who can see what?

What to look at. Log in as a brand-new test customer. Then try to reach another customer’s information: change a number in the web address, open a shared link in a private window, ask your own AI feature about “the previous customer.”

A bad answer. You see something that isn’t yours. Prototypes are built for one person, so they often treat “logged in” as the only rule. That works until customer two arrives, and then it’s a data leak waiting for someone curious.

What to do. Every record needs an owner, and every request needs to check that the person asking is that owner. If your tool can’t do that, that’s the finding, and it’s the most important one in this post. A leak of someone else’s data is the one failure you cannot apologise your way out of, especially with customers in the EU and UK, where regulators take it seriously.

Check 3: What is the worst a single user can cost you?

What to look at. Open the billing page of every service your product calls, especially the AI provider. Then ask what happens if one user, or one bug, calls it ten thousand times.

A bad answer. There’s no spending limit, the key is shared across everything, and you’d learn about a problem from the invoice. The usual version: a loop that retries forever, or one enthusiastic customer pasting in huge documents, and a month’s budget gone over a weekend.

What to do. Set a hard monthly cap at the provider. Use separate keys for testing and for customers. Add an alert at 50% of your normal spend. It takes an hour and it’s the cheapest insurance you will ever buy.

Check 4: Who finds out first when it breaks?

What to look at. The last time something failed, how did you learn? Be honest.

A bad answer. “A customer emailed me.” If customers are your monitoring system, you are running a product with the worst alarm available, and you only hear from the ones who bother to write. The rest just leave.

What to do. You need one thing: a message to your phone when the core flow fails. Not a dashboard. A single test that runs every few minutes, does what a customer does, and pings you when it can’t.

The one rule to keep

Here is the artifact. Pin it somewhere you’ll see it:

If a failure would cost a customer money, expose their data, or cost you more than a week of revenue, it needs a safeguard before the next customer, not after.

That’s the whole test. It isn’t “is my tech good enough?” It’s “what happens to someone else when this fails?”

What I’d tell you over coffee

Don’t rebuild. Founders hear all this and conclude they must throw the prototype away and start over, which is usually the most expensive mistake available. The idea, the flows and the customer feedback inside your prototype are the valuable part, and they transfer.

What you need is an honest audit of the four things above, then fixes in the order they hurt: data first, access second, cost third, alerting fourth. Some of it you can do this week yourself. Some of it, mainly the access rules, is worth handing to a senior engineer who has done it before, because a mistake there is silent until it’s catastrophic.

You crossed the line when the first invoice was paid. The only question left is whether your product knows it.

Prototype Rescue — from €6,000, 2–3 weeks. we take what you already built with a no-code tool, an AI assistant or a freelancer who is gone, and make it real: honest audit, proper auth and data model, repeatable deploys, monitoring.

It starts with a free product teardown: two hours on what you are building, what already exists, and what is actually blocking launch. You leave with a written plan and a realistic number, whether or not you work with us. Book a teardown · What it costs