TL;DR
- The code the AI wrote is usually fine. What breaks in production is what the AI never set up: configuration, secrets, who's allowed to see what, and what happens when more than five people show up at once.
- Four gates sit between what you have and something real people can use. It works on my machine, then someone else can run it, then real users can't break it, then you can fix it at 2am. The order isn't negotiable, because you can't secure something you can't hand over.
- Most of the remaining work is naming things the AI left unnamed: which key belongs to which service, which data is private, and what "logged in" actually means inside your app. Very little of it is coding.
- The wall most people hit isn't technical. It's that they can't hand the thing to anyone, including a person they've just paid.
- You don't need to become an engineer to clear these gates. You need to know what to check, and at some point you need one person who's shipped before to look at what you built.
The four gates between a prototype and a production app
Read the table from the top and stop at the first row you can't honestly claim. Each gate depends on the one before it, which is why people who skip ahead to the security row end up doing it twice. You can't lock down an app you can't hand to anyone. The last column is where I watch people get stuck.
| Gate | What it means in plain English | What has to be true to clear it | Where people get stuck |
|---|---|---|---|
| 1. It works on my machine | You have something that runs. You don't yet have something you can describe | You can say what it does, what data it holds, and which outside service each key belongs to, without opening the code | Mistaking "it runs" for "it's nearly done" |
| 2. Someone else can run it | The app no longer depends on you being in the room | Secrets are out of the code, the setup is written down, and someone who isn't you has actually followed it and got it running | Handing over a folder that only ever worked on one laptop |
| 3. Real users can't break it | Other people's data is now your problem | Nothing secret is visible in the browser, the database refuses requests by default, and a second test account can't see the first one's data | Assuming the AI switched security on, because it never said it didn't |
| 4. You can fix it at 2am | It will break. The question is whether you find out from an alert or from a customer | Errors are logged where you can read them, you've restored from a backup on purpose once, and you can put yesterday's version back without asking anyone | Shipping with no way back, then being too scared to touch it |
Where are you now?
There's no score here. Go down the six statements below and find the first one you can't say yes to with a straight face. That's your gate, and that's where you start reading. If you're unsure whether a yes is really a yes, treat it as a no. Everyone I've watched skip a gate has come back to it later, and it cost more the second time.
- My app runs somewhere that isn't the laptop I built it on. (Gate 1 to 2)
- Someone else could get it running from my project folder, without me on a call. (Gate 2)
- None of my passwords or API keys are typed into the code, and none of them are visible in the browser. (Gate 3)
- If a stranger signs up, they cannot see another user's data, and I've checked this myself, with a second account. (Gate 3)
- I know what my app does if 500 people use it at once instead of 5. (Gate 4)
- If it broke at 2am, I could put it back the way it was an hour ago. (Gate 4)
The first statement you can't say "yes" to with a straight face is your gate. Start there.
- Can't say yes to 1, start at Gate 1.
- Yes to 1, not 2, start at Gate 2.
- Yes to 1 and 2, shaky on 3 or 4, start at Gate 3. Don't skip it. This is the one that stops being your problem and starts being your users'.
- Yes to 1 through 4, not 5 or 6, start at Gate 4.
- Yes to all six, go straight to Common roadblocks. You're closer than you think, and the things that catch people at your stage are in that table.
Gate 1: It works on my machine - finding out what you actually built
People arrive at a mentor holding an app they cannot describe. They can open it, they can click through it, they can show you it working, and then you ask what data it stores and where, and the room goes quiet. That's Gate 1. It has nothing to do with writing code and everything to do with being able to say, out loud, what you're holding.
"It runs" and "you can describe it" are different states, and only one can be handed to another person. The AI built your app in pieces. Every piece was asked to work. None was ever asked to explain itself.
Start with the keys. Somewhere in your project there are API keys: passwords that let your app talk to another company's service, like the AI model, the database, or the payment processor. The AI put them somewhere. It never told you which key belongs to which service, and it never mentioned that anyone holding one can spend your money with it. Your first job is a list, one line per service.
Then write the paragraph: what the app does, what data it stores, and who it's for, without opening the code. If you can't yet, that's the work, not a verdict on you. One of the authors on the MentorCruise community blog shipped 1.5 million lines of production code in six months without being an engineer. What separates you from that is a list and a paragraph.
| Dimension | What the AI handed you | After Gate 1 |
|---|---|---|
| What you have | A folder that runs | A thing you can describe in one paragraph |
| Your keys | Wherever the AI put them | A list you wrote, service by service |
| Your safety net | One copy, on one laptop | A copy you've proven you can restore from |
Before you move to Gate 2, you need:
- One paragraph, written by you, saying what your app does, what data it stores, and who it's for, written without opening the code.
- A single list of every outside service the app talks to (the AI model, the database, email, payments) and which key belongs to which one.
- The whole project in one place you can copy, and you've copied it once, to a second location, to check that you can.
- The app started from scratch, from that copy, on your own machine, without guessing at a missing step.
Gate 2: Someone else can run it - getting the app out of your head
Your app has dependencies you can't see, and most of them are you. A setting you typed in once and forgot. A file that only exists on your desktop. A step you always do without thinking about it. None of that travels. Gate 2 is the work of getting every one of those out of your head and off your laptop, and into something a stranger can follow.
Your keys are almost certainly typed straight into your code right now. That's how the AI wrote them, because you asked it to make the thing work. They have to come out. Move them into what's called an environment variable, a setting that lives on the server rather than in the code, so it never ends up in a file anyone can read.
Taking a key out of the code is not the same as making it safe. GitHub's guidance on removing sensitive data from a repository is blunt: if the thing you're removing is a password, token, or credential, the first step is to revoke or rotate it, because deleting it afterwards doesn't end the exposure. My own rule goes further. If a key has ever been in your code, a screenshot, or a chat window with an AI, treat it as public and replace it. Rotating one takes ninety seconds.
Then write the file that lets someone else start it. It's usually called a README: a plain text document saying what to install, what settings to fill in, and how to start the app. The test is whether a person who is not you has followed it and got the app running without messaging you once. Finding that person is most of what the Claude Code mentors on our site do all day.
| Dimension | Gate 1 | Gate 2 |
|---|---|---|
| Where your secrets live | Typed into the code | In configuration the code reads when it starts |
| Who can run it | You | Anyone who follows your written setup |
| Where it runs | Your laptop | Somewhere with a URL that still works when your laptop is shut |
| What "done" means | It works | It works without you |
Before you move to Gate 3, you need:
- Every password, key, and token taken out of the code and moved into configuration the app reads when it starts.
- Every key that has ever been in the code, or a screenshot, or a chat with the AI, rotated. Assume it's public, because it might be.
- A written setup file a stranger could follow, with no step in it that says "ask me".
- Someone who isn't you has actually followed that file and got the app running. Not "could in theory". Has.
- The app running somewhere that isn't your laptop, on a URL that works when your laptop is closed.
Gate 3: Real users can't break it - when it stops being your problem
Nothing in your app told you security was off. It didn't warn you, it didn't flag it, it just never came up, because you never asked for it and the AI doesn't volunteer. Kuberns, a company whose entire business is hosting apps like yours, says the code is usually fine and configuration is what breaks. That's the good news and the bad news at once. Gate 3 is the configuration nobody wrote.
MindStudio, which builds AI apps for a living, publishes the list of what actually fails, and none of it is the code being wrong. Settings the app expects that nobody set. A database connection left half-configured. Keys the browser can read. Data open to anyone who asks, because nobody closed it.
Here's the one that catches everybody. Anything your app sends to the browser, the person using the browser can read. All of it. Every browser has a "view source" option, which shows the raw page underneath the pretty one. If your API key went somewhere the browser can see, it's published. Open your app, view the source, search for your own key, and find nothing. That takes a minute.
The other one is quieter and worse. Most databases start life open: they answer any question anyone asks, and wait for someone to tell them not to. Nobody told yours. So make a second account, log in as that stranger, and try to see the first account's data. If you can, so can anyone. That single check is the difference between a bug and a breach, and it's the moment the cost stops landing on you and starts landing on people who trusted you. It is, more or less, the trap that catches founders building faster than they can check.
| Dimension | Gate 2 | Gate 3 |
|---|---|---|
| Data access | Open unless someone closed it | Refused unless someone opened it |
| Who you're protecting | Yourself | Your users |
| Your secrets | Out of the code | Out of the browser too |
| What a mistake costs | Your evening | Someone else's data |
Before you move to Gate 4, you need:
- Nothing secret visible in the browser. Open your own app, view the page source, and search it for your own API key. Find nothing.
- A database that refuses by default. A logged-out stranger and a logged-in stranger both get nothing they aren't entitled to.
- A second test account you made yourself, which you have confirmed by hand cannot see the first account's data.
- Every form fed deliberate garbage: an empty field, a 10,000-character string, a stray bit of code. The app refused it without falling over.
- The site served over HTTPS, which is the encrypted version of a web address, and refusing to load without it.
Gate 4: You can fix it at 2am - the gate everyone skips
Here's how the projects I see actually die. Not at launch. Three weeks later, when something breaks, and the person who built it has no idea what changed, no way to put yesterday's version back, and no appetite for making it worse. So they stop touching it. The app stays up. Nobody fixes anything. Gate 4 is everything that stops that from being you.
A backup you have never restored is not a backup. It's a folder you feel good about. The highest-value hour in this article is the one where you take a backup, restore it on purpose while nothing is wrong, and watch the app come back. Do it once and you'll never be frightened of your own app in the same way again.
The same goes for putting the previous version back, which is called a rollback: you undo today's change and return to yesterday's working app. If you can't do that in a few minutes, without asking anyone's permission, every change becomes a one-way door. It's also, roughly, the ceiling that vibe coding runs into.
Then there's how you find out. Right now you find out when a customer emails, which means every problem gets a witness before it gets a fix. Errors need writing down somewhere you can read them, with the time, the person it happened to, and what failed. One alert is enough to begin with. On load, MindStudio's list is unglamorous: apps that ask the database the same question hundreds of times when once would do, keep nothing in short-term memory, and open a brand new connection for every visitor. Fine for five people. It falls over at five hundred.
| Dimension | Gate 3 | Gate 4 |
|---|---|---|
| How you find out it broke | A user emails you | An alert reaches you |
| Your recovery plan | Hope | A restore you've rehearsed |
| What you know about load | Nothing | What breaks first, and roughly when |
You're operating at this level when:
- When something breaks, you find out from an alert, not from a customer.
- Your errors are written down somewhere you can read them, with the time, the user, and the thing that failed.
- You have restored the app from a backup at least once, on purpose, while nothing was wrong. A backup you've never restored isn't a backup.
- You can put yesterday's working version back without asking anyone for permission or help.
- You know roughly what the app costs to run per user, and what happens to that number if a hundred people arrive at once.
Common roadblocks
Every one of these has walked into a mentor session in the last year, usually with an apology attached. None of them is a personal failing. Read the middle column first, because the mechanism is almost always something the AI couldn't see rather than something you got wrong, and once you can name the mechanism the fix stops being mysterious.
Teresa Torres calls the second row the doom loop, and her way out is the same as mine: plan before you prompt, and review what comes back.
| Roadblock | Why it happens | What actually gets you past it |
|---|---|---|
| You keep asking the AI to fix the deployment, and it keeps confidently failing | The AI can only see your code. It can't see your hosting account, your DNS, or the setting you never set, so it guesses, and its guesses sound exactly as confident as its facts | Stop asking it to fix it. Ask it to explain what it needs from you: "list every environment variable this app expects, and what each one is for." Then go and set them yourself |
| Every fix breaks something else | You're changing code you can't read, with no way to tell you've broken something until a user finds it | Get the app into a state you can return to before you change anything. A copy you can restore from is worth more than any individual fix |
| You don't know what to ask for, so you don't ask | The vocabulary is the barrier, not the work. You can't search for a thing you can't name | Take the gate you're stuck at and read its exit criteria out loud. Those sentences are the question. You don't need the jargon to ask them |
| The engineer you hired can't help you either | You handed over a codebase nobody can explain, including you. So the first thing any competent person has to do is read the whole thing, and reading it is the expensive part | Clear Gates 1 and 2 before you hire anyone. A project someone can actually run is a project someone can actually quote for |
| You shipped it, and now you're too scared to touch it | You never built a way back. Every change is a one-way door, so the rational move is to change nothing, and the project quietly dies | Rehearse a restore while nothing is wrong. Once you know you can undo, you'll start shipping again |
Tools and resources
Nothing here is a platform you have to buy. These are the four things I'd actually reach for, and I've named which gate each one belongs to, because a tool used at the wrong gate is just another tab. Product building with AI tools is now about one in twelve of the things people come to us asking for help with, so the crowd you're in is bigger than it feels at 1am.
Here's what I'd use, and where:
- at Gate 1, the AI that built the app is your best tool for describing it. Ask it to list every environment variable the app expects and what each is for, then to write one paragraph on what the app does and what data it stores. It's good at this, and it's free.
- at Gate 2, whichever host you deploy to (Vercel, Railway, Render, Fly) has a settings page for environment variables. That page is where your keys live from now on, and the deploy step is what gets the app off your laptop and onto a URL.
- at Gate 3, your browser and twenty minutes. View source, search for your key, make a second account, try to see the first one's data. No budget, highest stakes.
- at Gate 4, your host's backup and restore buttons, plus wherever it keeps the error log. Set one alert to begin with: tell me when the app returns an error. One alert you read beats five you ignore.
If you want a second pair of eyes before you open this up to real users, that's what a work review session is for. Someone who has shipped before reads what you built and tells you which of these gates you've actually cleared, rather than which ones you think you have. It's $119, there are 214 mentors who do it, and we accept fewer than 5% of the people who apply to mentor, which is the only reason a one-off review from a stranger is worth anything. It's a one-off, and it's meant to be. Most people don't need a mentor forever. They need one person, once, to tell them what they can't see.
FAQs
These are the four questions people ask me with the door closed. They're embarrassed by all of them, which is exactly why nobody writes a straight answer down anywhere. There's nothing embarrassing in here. Not knowing the word for a thing has never once stopped anybody from understanding the thing, and every one of these has a short, honest answer.
What's the difference between a prototype and a production app?
A prototype proves the idea can work. A production app survives people who aren't you. Nobody else draws that line for you, because it's four specific gates: it runs on your machine, someone else can run it, real users can't break it, and you can fix it at 2am. A prototype has cleared the first one. A production app has cleared all four. Everything in between is configuration, not cleverness.
Can I just ask Claude to review the code Claude wrote?
Yes, and you should, because it's free and it catches real things. It just doesn't close the loop, and the reason has nothing to do with how good the AI is. It's that you have no way to judge whether its review was any good. A review you can't grade isn't a review, it's a second opinion from the same source. Our validation playbook covers this properly, though fair warning: it's written for engineers.
Do I need to learn to code before I ship what I built?
No. But you do need to learn to check, and those are different skills. Every gate here is a verification skill: can you describe it, can you hand it over, can you break into it, can you put it back. None of that requires writing a line of code. The ceiling is real, though. The Stack Overflow Blog makes the case that building without code knowledge carries risks the tools never show you. Checking is how you see them.
How do I know if what I built is safe to put real users' data in?
You don't know. That's the answer, and it's the problem. You can find out this afternoon with three checks. Open your app, view the page source, and search for your own API key: you should find nothing. Make a second account and try to see the first one's data: you should fail. Confirm your database refuses requests by default. If any of the three goes the wrong way, you're not ready, and now you know what to fix.
