Fixing and productionizing AI-generated (vibe-coded) applications
An AI-generated application is software produced largely by prompting AI coding tools, often by a founder or a small team without an engineer. Many work. Few are ready for real users. AL+ takes these applications, and ordinary prototypes and MVPs, from demo to production: we keep what works, fix what is unsafe, add what is missing, and stay responsible afterwards.
What has changed, and what has not
Producing code used to be the expensive part of software. It is now often the cheap part. A person with a clear idea can have a functioning product without hiring a developer, and that is mostly good: more things get built by the people who understand the problem.
Everything after the code exists has not changed. Deployment, monitoring, backups, security updates, access control, performance under load, data migrations, and the slow accumulation of changes a real business demands. This work was never about typing speed. It is about understanding a system well enough to be responsible for it, and AI tools do not currently hold that role. Someone has to.
Where AI-generated applications fail in production
The failures we find are rarely about code style. They repeat across stacks and tools.
-
Security is assumed
Authorization checks that exist only in the browser. Database access rules never enabled. Secrets committed to the repository. Input passed to the database unvalidated. Each looks fine in a demo, because a demo has one honest user.
-
Nobody can explain the system
The team can describe what they asked for, not what they got. When something breaks, the debugging conversation starts from zero every time.
-
Design is local, not global
Each feature was generated to satisfy its own prompt. Together they form three ways of doing one thing, duplicated logic, and data living in more places than it should. Each piece is reasonable. The whole is hard to change.
-
Failure is not handled
Generated code assumes every call succeeds. One timeout, one unexpected response, and users see a blank screen with no retry, no message, and no record of what happened.
-
Operations were never designed
There is a deployment because the hosting platform made one. No backups, no alerts, no staging environment, and no plan for the day the database fills up or the free tier ends.
-
Dependencies are frozen
The project pinned whatever versions existed the week it was generated. A year later several are unsupported, and upgrading means understanding code nobody has read.
How AL+ productionizes an AI-generated application
Usually not by rewriting it. The right move is to keep what works and add what is missing, in this order.
-
1. Read the whole system
We read every part of the application and its configuration and write down how it actually works: data model, authentication, external services, scheduled jobs, deployment. From now on changes start from knowledge.
-
2. Fix what is unsafe
Authentication and authorization reviewed by hand and enforced on the server. Secrets moved out of the code and rotated. Validation where user input meets the database. Access to production reduced to the people who need it.
-
3. Add operations
Tested backups. Monitoring that alerts a human. A staging environment. Deployments that can be rolled back. Error tracking so failures are seen before customers report them.
-
4. Make it coherent
Consolidate the three ways of doing one thing into one. Give each piece of data one home. Add tests around the parts that matter most, so the AI tools you keep using can be trusted again.
-
5. Plan the dependencies
Upgrade what is unsupported now, and put the rest on a schedule so the next upgrade is small.
-
6. Stay responsible
After this the application is ordinary production software, and it needs what all production software needs: an owner who maintains it. AI tools become more useful, not less, because changes land in a system someone understands and can verify.
The criteria we check are published as a production-readiness checklist for AI-generated applications. It applies equally to a prototype built by hand.
Where AL+ fits, and where it does not
-
A good fit
Web applications and SaaS products generated with AI tools or built quickly by hand, that have or are about to have paying users. Founders who want to keep using AI tools, with an engineer responsible for the result. Teams that need a prototype turned into something they can operate.
-
Not a fit
Applications with no users and no plan for any; a review is cheaper than production readiness. Requests to "just make it work" by tomorrow with no ownership afterwards. We are not an AI agency and do not sell prompt engineering or model integration as a service.
Related thoughts
-
Production-readiness checklist for AI-generated applications
Thirty concrete checks that separate a working AI-generated (vibe-coded) prototype from production software: security, data, failure handling, operations, coherence, dependencies, and ownership.
-
Software needs an owner
Software becomes expensive when nobody clearly owns it. Ownership is a role, not a repository permission, and most struggling systems are missing it.
-
AI-built software still needs an engineer
AI changes how code is produced. It does not remove technical responsibility. Software generated quickly still needs someone who understands it and answers for it in production.
Have an application that works in the demo but not in production?
Write a few sentences about the system, who built it, and what worries you. You will hear back from the people who would do the work.