Is every table or collection restricted server-side, not just hidden in the UI?
A hidden button is not a permission. Anyone can call the API directly with the key that ships in your front end.
Production readiness
28 questions between your AI-built app and real users.
This is the list we actually work through when someone sends a repo, in the order we work through it. Answer each one honestly. The 7 marked blocker are the ones where a "no" means you should not put real customer data in it yet — everything else is a matter of when, not whether.
Published in full on purpose. If you read this and fix everything yourself, that is a good outcome — it is the same list either way.
Area 1 of 7
Access control
Who can see and change what. This is where AI-built apps fail most often and most expensively, because the failure is invisible until someone looks.
Have you tried to read another user’s data while signed in as yourself?
The most common real breach in these apps is not an attack, it is one customer seeing another customer’s records.
Do password reset, email verification, and session expiry actually work end to end?
Sign-in is the part the generator finishes. The flows around it are where your first users get stuck and email you.
Can an account be deleted, with its data, on request?
Under GDPR this is not optional, and retrofitting deletion across a schema you did not design for it is slow.
Area 2 of 7
Secrets and environments
Where your keys live, and whether production and your laptop are actually different places.
Are production and development pointed at different databases?
Shared environments mean a local test run can delete real customer data, and it usually does so on a Friday.
Is every secret in the host’s environment settings rather than in the repo?
A committed key stays live in the git history and in every fork long after you delete the line.
Do you know which keys are safe to expose in the browser bundle and which are not?
Publishable and secret keys look alike. One in the wrong place is a bill you did not authorise.
Can you rotate a leaked key without downtime?
If rotation means editing code and redeploying by hand, it will not happen fast enough to matter.
Area 3 of 7
Data and migrations
Whether your schema can change after real data lands in it, and whether that data can be recovered.
Are schema changes in version-controlled migration files?
Changes clicked into a console cannot be reproduced, reviewed, or rolled back. A new environment cannot be built at all.
Do backups run automatically?
Most managed databases back up by default and most self-hosted ones do not. Assumption is the failure mode here.
Have you restored one of those backups, once, into a scratch database?
An untested backup is a belief, not a backup. The failure is always discovered on the day it matters.
Does the database enforce its own constraints — not-null, unique, foreign keys?
Validation only in the app means the first bug writes data that every later query has to work around forever.
Area 4 of 7
Deployment and CI
Whether shipping is a routine event or a careful one.
Does a push to your main branch build and deploy on its own?
Manual deploys are rare deploys. Rare deploys are big deploys, and big deploys are the ones that break.
Does anything stop a failing build from reaching production?
Tests that nothing runs are documentation, and they rot within a week of being written.
Can you roll back to the previous version in under five minutes?
Without a rollback path, every incident becomes a debugging session while users are watching.
Is the app on your own domain with valid TLS?
A platform subdomain reads as a demo, and some corporate networks block the unclassified ones outright.
Area 5 of 7
Knowing when it breaks
Right now, would you find out about an outage from a dashboard or from a customer?
Are server and browser errors reported somewhere you actually read?
Errors logged to a console nobody opens are errors nobody fixes.
Is something checking from outside that the site is up?
Internal health checks pass happily while DNS, TLS, or the host itself is what failed.
Can you search the logs for one user’s failed request?
Without searchable logs, "it didn’t work for me" is unanswerable, and you will get that message.
Do the alerts reach a human on a phone?
An alert into an unwatched channel is the same as no alert, and costs the same to set up as a real one.
Area 6 of 7
Legal and compliance
The part that decides whether an EU business or an IT department is allowed to use what you built, regardless of how good it is.
Is there a privacy policy naming your legal entity and what you collect?
Selling to EU customers without one is a live GDPR exposure, and B2B buyers check before procurement does.
Is analytics or tracking gated behind consent?
Loading a tracker before consent is the single most commonly enforced GDPR failure on small sites.
Do you know which third parties your app sends personal data to?
Every SDK the generator added is a processor you are answerable for, whether or not you knew it was there.
Is there a documented retention period for the data you hold?
"Forever" is a decision, not a default, and it is the wrong one for most of what these apps store.
Area 7 of 7
Running it after launch
What happens in the weeks after the launch you are focused on.
Is there a written runbook — deploy, roll back, restore, rotate a key?
Everything lives in your head until the week you are ill or on a flight.
Do you know the monthly cost at ten times current traffic?
Serverless and per-request pricing scale smoothly right up to the invoice that ends the experiment.
Are dependencies checked for known advisories?
Generated projects pin whatever resolved on the day, including packages with published vulnerabilities.
Could another engineer pick this up from the README alone?
An app only you can run is an app that stops the day you stop, and it is worth less if you ever sell it.
What your score means
Count the "no"s. In the repos I read, a prototype that has never been deployed averages somewhere around fifteen — that is normal and it is not a judgement on your build. The number is only useful for one thing: telling you whether you are days away from launching or weeks.
Do not launch yet
A blocker is something you cannot undo after the fact: leaked data stays leaked, a deleted production database stays deleted. These are usually a day or two each, and they come first regardless of what else is on your roadmap.
You can launch to a small first cohort
Ship to people you can email personally. Fix the serious items during that window, before the volume arrives that makes each one expensive.
You are ready
Genuinely. Ship it. Come back to the rest when growth or a customer makes one of them urgent — that is the right trigger for all of them.
Or have someone else answer them
Send the repo and I will work through this list myself and write back the three gaps that matter most for your build, with what each one takes to close. Free, in writing, within two business days, no call required.
Common questions
What does "production ready" actually mean for an AI-built app?
It means the app can survive people who are not you: users who do the wrong thing, a deploy that goes badly, a key that leaks, a database that needs restoring. Concretely, it is the 28 questions on this page — and the 7 marked as blockers are the ones where the honest answer is that you should not put real users on it yet.
How long does it take to get from prototype to production?
For a typical AI-built app with no paying users yet, about two weeks: a few days closing blockers, a few days on deployment, CI and monitoring, then a launch week with someone on call. Apps that already hold customer data or take payments take longer, because every change has to be reversible while the thing stays up.
Can I do this myself?
Yes, and the list is published in full for exactly that reason. If you are technical and have the time, work down it in order — access control first, then secrets and environments, then backups. Most of it is a day or two each. People hire us when the launch is what matters and the checklist is what is in the way.
What order should I fix things in?
Access control first, always: a data leak is the only item on this list you cannot undo. Then environment separation and secrets, because those prevent the accidents. Then backups you have tested. Deployment, CI and monitoring after that — they make everything else cheaper, but they protect nothing on their own.
How much does it cost to get this done?
The teardown is free — send the repo, get the three biggest gaps back in writing. A complete written review against every item here is €750, fixed price, credited back if you continue. Doing the work and taking it live is from €7,500 for a typical two-week fixed-scope sprint. Prices in EUR, excluding VAT. USD invoicing available.
Something else? kristian.dienes@ladient.sk, or book 30 minutes.