The prototype-to-production gap

A prototype answers a different question

A prototype asks whether the core experience is possible. Production software must answer harder questions: Can unauthorized users reach protected data? What happens when a dependency fails? Can a release be rolled back? Who receives an alert? Can a new developer understand the system?

AI coding tools optimize for producing a plausible implementation from available context. They cannot know requirements that were never stated, production data they cannot see, or business constraints that remain in a founder’s head. Human review and operational testing remain necessary.

Security and identity before launch

Start with the trust boundaries: users, administrators, background jobs, external APIs, databases, file storage, and model providers. Verify authentication, authorization on every protected server action, tenant isolation, secure session handling, and rate limits. Client-side hiding is not authorization.

Secrets should be stored outside source control, rotated when exposure is suspected, and separated by environment. Validate inputs at trust boundaries, encode outputs for their context, and avoid returning internal errors or stack traces to users.

• Test horizontal and vertical authorization failures.
• Separate development, staging, and production credentials.
• Review dependency and container vulnerabilities.
• Protect high-cost AI endpoints from abuse and unbounded requests.
• Define retention and deletion behavior for customer data.

Reliability, deployment, and recovery

A production system needs predictable failure behavior. Set timeouts for network calls, use retries only when operations are safe to repeat, and prevent one unavailable provider from exhausting application resources. Critical background work needs durable queues or an equivalent recovery mechanism.

Every release path should have automated checks, an observable deployment, and a rollback procedure that has been exercised. Database changes deserve special care because application rollback does not automatically reverse a destructive migration.

• Health checks that represent real dependencies rather than process uptime alone.
• Structured logs and actionable error monitoring.
• Backups with documented restore tests.
• Deployment approvals or protections appropriate to the team.
• A written incident owner and customer-communication path.

Performance and cost are production requirements

AI-assisted products can hide expensive behavior behind an attractive interface. Measure database queries, API fan-out, model tokens, background work, file storage, and egress under realistic traffic. Put budgets and limits around any user action capable of creating material cost.

Test slow networks, larger accounts, concurrent users, third-party throttling, and partial failures. A system that performs well with a founder’s sample data may degrade sharply with real customer history.

• Set service-level indicators for availability and latency.
• Load-test the highest-value and highest-cost paths.
• Add alerts tied to user impact and spend anomalies.
• Cache deliberately and define invalidation behavior.

Maintainability and ownership

Before launch, another qualified person should be able to run the application, explain its major components, deploy a change, locate production services, and restore from a backup. If only the original prompt author can do those things, the company has a continuity risk.

Document architecture, environments, dependencies, data stores, domains, vendors, deployment, rollback, and incident contacts. Record why consequential decisions were made. Documentation should be tested through an actual handoff, not judged by file count.

A practical launch gate

Classify findings by customer impact and reversibility. Block launch for broken authorization, exposed secrets, destructive data behavior, missing recovery for critical data, or release processes that cannot be reversed. Schedule lower-risk maintainability work with an owner and deadline.

Finally, run a tabletop incident: assume the primary service is unavailable, a credential is compromised, or the original developer cannot respond. Walk through detection, containment, recovery, and communication. The gaps found in an hour-long exercise are often more valuable than another round of feature polish.