AI coding tools let people build a working prototype with less development experience. A growing share of our engineering work starts with those applications.

Before an application serves paying users, we review how it handles access, data, payments, and failures. These are the areas we examine first in an AI-assisted codebase.

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.
  • Data model. A generated schema may support the demo but lack constraints needed for production data. Missing constraints, absent indexes, and columns carrying multiple meanings cost a day to fix early and a migration project to fix later.
  • Permissions and sessions. A demo with one user does not exercise the full permission model. Under real traffic, session handling, password resets, and per-route authorization all need verification, and the last of these fails most often.
  • Payment reconciliation. Payment testing covers retries, double clicks, duplicate webhooks, and refunds that must match the accounting records.
  • Monitoring and recovery. During development, the builder may be the only person watching for errors. 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.

What we keep and what we change

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.