Guide · for an owner who built it themselves
What "Production-Ready" Actually Means for an App You Built with AI
Will Pickeral, William Belle LLC · support@williambelle.co
Your app works. People use it, or they are about to. Somewhere along the way you have been told it is not "production-ready", probably without being told what that would involve.
It is not one thing, and it is not a certificate anyone issues. It is a list of specific gaps, most of which have nothing to do with your code being good or bad. Here is the whole list, what each one costs you when it is missing, and — the part nobody tells you — which of them you can honestly skip.
First, the part that is already true
You built a working application. That is the hard part in every sense that matters to your business, and the fact that a tool helped is no more interesting than the fact that a compiler helped.
What follows is not a critique of what you made. Every item below is missing from most software written by professionals too, at least at first. The difference is that a team eventually notices, and a person building alone has nobody to mention it.
The list
Nine gaps. Read them as questions about your situation rather than as a homework assignment.
Do you own where it runs?
The accounts the app runs in should be in your name, with your billing on them. If it lives on the hosting your build tool provides, you are one pricing change or closed account away from a bad week, and you cannot answer a customer who asks where their data is kept.
What it costs when missing: you cannot leave, and you cannot say where things are.
Is your code somewhere other than the tool that wrote it?
In a repository, with a history of every change. Not a zip on your machine, not only inside the builder's interface.
What it costs when missing: no way to see what changed when something breaks, no way back to the version that worked, and nobody else can pick it up. This is the single cheapest item on the list and the one most often skipped.
Can you put a change live without being afraid?
Somebody makes a change; something makes it live. If that is you, by hand, at night, and there is no way to reverse it, every fix is a gamble.
What it costs when missing: you stop making small improvements, because each one carries the risk of the whole thing. The app quietly stops getting better.
If it broke right now, could you go back?
Not "is there a backup somewhere" — has anyone ever restored one and confirmed it worked? An untested backup is a belief.
What it costs when missing: the worst day you will ever have with this software.
Can you reach your passwords and keys, and can nobody else?
Passwords, API keys, and connection strings belong in a locked store the app reads from, not written into the code. If they are in the code, everyone who has ever had a copy of it has them, forever.
What it costs when missing: a leak you cannot undo by changing a password, because the old one is still sitting in a file somebody has.
Does each person reach only their own records?
A sign-in page keeps strangers out. That is a different job from keeping your customers apart from each other. The common failure is that a signed-in user can change a number in the address bar and see somebody else's data.
You can test this yourself in five minutes, with two accounts and a browser. Do it today, whatever else you take from this page.
What it costs when missing: the failure that ends a small software business.
Do you find out before your customers do?
Something checking that the app is up and answering, and telling a person when it is not. Without it, your monitoring is a customer's email.
What it costs when missing: hours of downtime you did not know about, and a customer who did.
Do you know what it costs to run?
Not roughly — the number, and what drives it. Cloud bills grow quietly, and the usual cause is capacity sized for a launch that already happened.
What it costs when missing: a bill that grows faster than the business does.
Is any of this written down?
One document: what runs where, who can reach it, what is backed up, how a change goes live. It is what you hand a customer who asks, and what makes you replaceable in the good sense — you could hire someone tomorrow.
What it costs when missing: every question takes a week, and everything depends on you remembering.
Which of these you can skip
An internal tool three people use is not a payment system, and treating them the same wastes money.
If your app holds no data anyone would miss and has no customers on it, the honest list is short: get the code into a repository, and know what it costs to run. The rest can wait until it is carrying something real.
If real people are relying on it, the first four are not optional: own the accounts, code in a repository, a way to undo a change, and a backup somebody has actually restored.
If other people's records are in it, add the two access items and the written document, and treat them as urgent rather than as a project for later.
Anybody who tells you every application needs all nine on day one is selling something. What decides it is what the app carries and who would notice if it stopped.
Doing it yourself
Several of these are genuinely a weekend's work if you are willing to read, and it would be dishonest to pretend otherwise.
Getting your code into a repository is an afternoon. Testing a backup is an hour. The access test above is five minutes. Those three remove a real share of the risk and cost nothing but your time.
Where it gets hard is the middle of the list — cloud accounts, keys, releases you can reverse. Not because any single step is difficult, but because getting them wrong is invisible until it matters, and the tool that helped you build the app is not good at telling you that something is set up in a way that will hurt later.
The technical detail, if you want to judge how deep this goes before deciding: pipelines for releasing safely, describing your cloud so it can be rebuilt, knowing your app is healthy, and working on a codebase nobody can safely change. They are written for engineers. They are also the honest answer to "what would you actually be doing."
If you hire it out
It is one piece of work, not nine purchases. Somebody reads what you have, tells you which of the nine actually apply to your situation, and quotes the work. That is worth saying because the list above reads like a shopping list and it is not one — most of these are the same afternoon's work as each other, and buying them separately costs more than buying them together.
What you should get at the end is the app running in accounts with your name on them, and a document you can hand to anybody, including the next person you hire. If a proposal does not end in you owning both, that is the question to ask about.
Get a free 20-minute review — show me what you have and I'll tell you where I'd start, and why. If the answer is that you are fine for now, that is what you'll hear. Nothing to prepare.