The demo went well. Someone on the team built a working version of the idea in a week with an AI app builder: a log-in screen, a dashboard, a form that saves to a real database. Everyone clicked through it. Then someone asked the question that matters: can we give this to customers next month?
I sit in a lot of first meetings at Brilean, and this is now the most common way they start. A founder opens a laptop, shows us something that works and asks how far it is from a real product. Sometimes the honest answer is a few weeks. Sometimes it's "start again, but keep everything you learned". Telling those two apart early is most of what that first conversation is for.
We've earned some opinions on this the hard way. Our work is mostly about what happens after launch day: a control system for more than 1,500 connected pellet stoves that can't go down on the first cold night of winter, a cashback platform that has run for over 1,000 days without a break, a tournament platform for pharmacists that had to hold up during a live national competition. None of that shows up in a demo. All of it shows up in production.
Why AI prototypes look finished
AI tools are very good at the part of software you can see: screens, flows, forms, lists. They're much less reliable at the part you can't see in a demo, and that's where most of the work in a real product lives.
A demo runs with one user, fifty rows of data and nothing going wrong. Production has thousands of users who mustn't see each other's data, tables that grow every day, and third-party services that fail at the worst possible moment.
That isn't a criticism of the tools. We use them every day, and they've changed how quickly we can test an idea with a client. It's a reason to be clear about what a demo can't tell you.
Five things a demo won't show you
1. Who can see whose data
This is the one that matters most. In a lot of AI-generated apps, the screen hides other customers' records, but the database will still hand them over to anyone who asks directly. The interface looks secure. The data isn't.
The test is simple: log in as one customer and try to fetch a record that belongs to another. If it comes back, the access rules live in the interface, not in the database, and that has to be fixed before anyone else logs in.
2. Where the secrets live
API keys, payment keys and admin credentials have a habit of ending up in code that runs in the browser, where anyone can read them. Generated code does what the prompt asked, and "connect to the payment provider" rarely comes with "and keep the key on the server".
3. What happens when something fails
An email that doesn't send. A payment confirmation that arrives twice. A partner API that goes down for an hour. A demo never meets these. A product meets them in its first week.
On the pellet stove platform, the hardest day of the year is the first properly cold one, when thousands of people switch their heating on from their phones within the same hour. You don't learn how a system behaves that morning by clicking through a demo in August. Ask whether there are backups, too, and whether anyone has ever restored one. A backup nobody has tested is a hope, not a plan.
4. Whether anyone else can maintain it
A prototype built through hundreds of prompts often has the same logic written three times in three places, no tests and no documentation. It works, but only the person who prompted it knows why. Before you invest in it, ask a developer who didn't build it to read the code and explain it back. If they can't, the next feature will cost more than it should.
Check who owns the accounts, too. The code, the database and the domain should sit under your company, not under someone's personal login. Our founder wrote more about ownership in who owns the software your grant paid for.
5. What it costs at real usage
AI features are charged per use. A summary that costs a fraction of a cent in a demo can become a serious monthly line once a few thousand people use it every day. The same goes for database and hosting plans with usage tiers. Work out the monthly bill at ten and a hundred times your current users before you promise a price to anyone.
Keep, harden or rebuild
When a prototype comes to us, we start where we start every project: with Align, before anyone writes a line of code. In practice, that means a short, focused review of the code, the data model and the accounts behind it. The answer usually falls into one of three paths.
Keep and harden
The data model makes sense and the structure is sound. The work is fixing access rules, moving secrets to the server, adding tests on the critical flows and setting up monitoring and backups. This is usually a matter of weeks, not months.
Keep the front, rebuild the back
The screens and flows were validated with real users and are worth keeping, but the data model or the permissions were wrong from the start. This is the most common outcome we see, and it's a good one: the hardest product decisions have already been made.
Rebuild, keep the learning
Sometimes the prototype's real job was to answer a question, and it did. What you keep is a tested idea and a far clearer specification than any written brief. That isn't a failure. It's the cheapest validation most teams will ever get.
Three things decide which path you're on: how sound the data model is, where the access rules live, and how much of the business logic runs in the browser.
Where AI still earns its place
None of this means taking AI out of the process. It's built into how we deliver: generating test cases from user stories, reviewing access rules, drafting documentation and running automated QA from the first sprint, not bolted on at the end.
What changes is who makes the decisions. We work in small, senior teams, and that's deliberate. In a prototype, the AI often makes the architectural choices by default. In a product, an experienced engineer makes them on purpose, and the AI does the heavy lifting around them. The right people doing the work, and AI handling the rest.
Before you put real users on it
- Log in as two different customers and try to see each other's data.
- Search the code that runs in the browser for keys. Anything secret moves to the server.
- Confirm backups exist, and restore one at least once.
- Make sure the code, the database and the domain sit in accounts your company owns.
- Estimate the monthly cost at ten and a hundred times your current users.
- Ask someone who didn't build it to read the code and explain it back to you.
An AI-built prototype is one of the best things a team can bring to a first meeting. It answers questions a brief never could. Just don't confuse "it works when I click it" with "it's ready for people I've never met".
At Brilean, we say we build for speed, scale and substance. AI tools have made the speed part easier than ever. Scale and substance are still the work. If you've got a prototype and you're not sure which of the three paths it's on, bring it to a first conversation. We're happy to take a look.
This article reflects our experience reviewing and taking over AI-built prototypes for clients. Every product is different, and a proper review of the code always has the final word.