"Production-ready" is the most load-bearing phrase in software sales and almost nobody defines it. It is doing the same work as "results-driven" or "enterprise-grade": it sounds like a standard and commits to nothing.
So here is a version with the failure written next to each item. A checklist you can fail is worth something; an adjective is not.
Can only the right people see the right things?
Passes when: a logged-in customer cannot reach another customer's records by editing the address bar, and a logged-out stranger cannot reach anything private at all.
Fails like: nothing. It looks identical. You find out when a customer mentions seeing a name they did not recognise.
Are your secrets actually secret?
Passes when: every key — database, payments, email — lives on the server only, and rotating one is a config change rather than a redeploy of the app.
Fails like: nothing, again, until somebody opens the browser console or reads the page source, both of which are menu items.
Does the app tell someone when it breaks?
Passes when: an unhandled error reaches a human within minutes, through a channel that human actually watches.
Fails like: silence that is indistinguishable from things going well. This is the one I would put first if I had to pick. A system whose failures are quiet gets more reassuring the more broken it becomes, because the complaints stop too — the customers just leave.
Can you change it without fear?
Passes when: there are automated tests over the parts that would cost money to get wrong, and you can run them in one command.
Fails like: a creeping unwillingness to touch anything. The app stops improving, and everyone involved describes this as "being careful".
Does it survive a second person?
Passes when: two people using it at once do not collide — no double bookings, no two customers assigned the same order number, no half-written record left behind when someone closes a tab mid-way.
Fails like: intermittent weirdness that cannot be reproduced and gets written off as a fluke three times before anyone takes it seriously.
Could someone else take it over?
Passes when: a competent developer who has never seen it can get it running locally from a written README, and the important decisions are explained somewhere.
Fails like: you being permanently on call for your own side project, and any future developer quoting you for a rewrite because reading it is harder than replacing it.
Is there a way back?
Passes when: the data is backed up, you have restored from that backup at least once, and you can roll back a bad deploy.
Fails like: a backup that has never been tested, which is not a backup. It is a belief.
What this list is not
It is not a feature list and it is not about elegance. You can pass every line here with code that would embarrass a senior engineer, and plenty of beautiful code fails most of them.
It is also not all-or-nothing. If you are putting five friendly customers on something, the error alerting and the access rules matter enormously and the handover documentation can wait. The point of writing the failures down is that you get to choose which ones you are accepting, rather than discovering later that you accepted all of them by default.
How to use it
Go through the seven, honestly, and mark each one pass, fail, or do not know. "Do not know" counts as fail for anything touching money or customer data.
If you come out with two or three fails, that is a normal result for something built fast, and it is a week or two of specific work rather than a rebuild. The expensive version is not having looked.
Run the free website check — the public-site version of the same instinct: specific findings, ranked by what would actually cost you.
If you want this checklist run against your own app by someone who has had to pass it himself, tell me what you have built. A written audit is a fixed price and you keep the document whatever you decide to do next.
