The tooling got good. Someone with an idea and a few free evenings can now ship a working product with AI doing most of the typing. We consider this a genuinely positive development, and a growing share of our engineering work now begins where those prototypes end.

Because a prototype in front of paying users stops being a prototype. It becomes production, and production has requirements the demo never had to meet. When a founder brings us an AI-assisted codebase, these are the areas we examine first.

The five gaps we check first

  • Credentials in the code. AI assistants tend to hardcode API keys: in the client bundle, in commit history, in seed files. We rotate every credential and move them into proper secret storage. A repository that was ever public should be treated as compromised.
  • A guessed data model. Ask a model for a schema and it produces one that works. Whether it survives real data is another matter. Missing constraints, absent indexes, and columns carrying multiple meanings cost a day to fix early and a migration project to fix later.
  • Authorization at the edges. Login worked in the demo because the demo had one user. Under real traffic, session handling, password resets, and per-route authorization all need verification, and the last of these fails most often.
  • Payments that reconcile. Charging a card is straightforward. The retry, the double click, the duplicate webhook, and the refund that must match your accounting are the actual work. Where money moves, we test hardest.
  • Monitoring that exists. During development, the builder is the monitoring. Real users encounter problems after hours and may not report them. Error tracking, uptime checks, and restore-tested backups turn silent failures into issues the team can address.

The encouraging part

Production readiness goes deeper than a polish pass. The prototypes we take to production typically keep 40 to 60 percent of their original code. We preserve the parts that work, then fix the structure, data model, security, and infrastructure where needed. We read the codebase, document the priorities, and quote the work. Afterward, we can operate the application under a managed plan or hand it back fully documented.

Shipping something people use is the hard part, and it is already done. The remaining work is making sure the application survives its own success.