An AI-built prototype is ready for production only when the team can explain, test and operate the system without relying on the generation history that created it. A production audit must verify architecture, identity, permissions, data integrity, dependency risk, failure behaviour, testing, deployment, observability, cost and ownership.

A prototype proves that a workflow can appear to work. A production system must keep working under real users, hostile inputs, partial failures, changing dependencies and operational pressure.

Project Supply can assess an AI-assisted application, define a remediation backlog and take the product through architecture, engineering, cloud, quality and security work. Begin with a scoped Technical Audit, not an automatic rewrite.

Why rapid prototypes fail differently

AI tools reduce the work needed to produce interfaces, CRUD flows and integrations. They also make it easy to create more code than the founding team can meaningfully review.

The risk is not that AI-generated code is inherently defective. The risk is that plausible output crosses architectural boundaries without a recorded decision. Authentication may be implemented in several places. Database access may bypass tenant filters. Secrets may leak into client code. Error handling may cover only the happy path. A dependency may be added because it solved one prompt, without anyone accepting its maintenance or licence implications.

The audit must examine the system that exists, not debate how much of it was generated.

Gate 1: Product and scope integrity

List the critical user journeys, the data each touches and the business outcome it must create. Separate launch-critical functions from demonstrations and unfinished experiments.

For each journey, define authorised actors, inputs, validation, state transitions, failure behaviour, data retention and completion evidence. If the team cannot state these rules, code review alone will not establish readiness.

Gate 2: Architecture and ownership

Map repositories, services, databases, queues, third-party APIs and environments. Identify which component owns every business rule and data entity.

Look for duplicate logic, circular dependencies, direct database access from inappropriate layers and integrations without timeouts or idempotency. A modular monolith can be entirely appropriate. The test is whether boundaries, ownership and change impact are intelligible.

Gate 3: Identity, tenancy and authorisation

Authentication identifies the user. Authorisation determines what the user may do. Test tenant isolation, server-side roles, session revocation, recovery, administrative access and API object-level authorisation. Hidden buttons and client-side guards are not security controls.

Gate 4: Data integrity and lifecycle

Inventory personal, financial, operational and derived data. Verify schema constraints, migrations, transaction boundaries, backup, restoration and deletion.

Test delayed and duplicate webhooks, retried requests and concurrent updates. Restore a backup in a controlled environment. A backup that has never been restored is an assumption.

Gate 5: Dependencies and supply chain

Create a dependency inventory. Check supported versions, known vulnerabilities, abandoned packages, licences and transitive dependencies. Protect dependency automation and repository applications as privileged actors.

Use NIST’s Secure Software Development Framework as a control reference appropriate to the product’s risk.

Gate 6: Testing that represents risk

Coverage percentages do not establish test quality. Map tests to failure impact. Include unit tests for business rules, integration and contract tests, authorisation and tenant-isolation tests, end-to-end critical journeys, migration and rollback tests, credible load tests and security testing.

Flaky tests are defects. A pipeline teams routinely ignore cannot protect a release.

Gate 7: Delivery and rollback

Require protected branches, reviewed changes, isolated environments, controlled secrets and traceable artefacts. Every release must answer: what changed, how failure will be detected and how the team will stop or reverse it.

Use backward-compatible data migrations and staged cutovers where risk justifies them.

Gate 8: Observability and incidents

Logs, metrics and traces should explain customer-impacting failure without exposing sensitive data. Define indicators for critical journeys, not infrastructure uptime alone. Create alerts with owners and runbooks. If one founder is the only person who can diagnose the system, the product has an ownership risk.

Gate 9: Cost and capacity

Model hosting, database, storage, transfer, APIs, email, observability and AI inference. Measure cost per active tenant, completed workflow or other useful unit. Add budgets and anomaly alerts.

What the audit should produce

A current architecture map, risk register, prioritised remediation backlog, launch blockers, accepted risks, test and observability gaps, deployment and rollback plan, cost model, ownership requirements and a go, conditional-go or no-go recommendation.

A practical production-readiness decision

Treat findings by consequence, not by code volume

Separate launch blockers from scheduled hardening. A blocker is a defect that can expose customer data, corrupt irreversible state, defeat tenant boundaries, prevent recovery or make incidents invisible. Maintainability issues still matter, but they should not obscure risks that can invalidate the product.

Test one complete business journey

Run a realistic path from identity and payment through the product’s core action, failure handling, audit trail and customer support response. This reveals gaps between individually working screens and a dependable production system. Repeat the journey with expired sessions, duplicate requests, partial outages and permission changes.

Leave with an owned remediation plan

Every finding should name its evidence, business impact, accountable owner, acceptance test and target release. The go-live decision should state what is fixed, what is temporarily controlled, what is consciously accepted and what evidence would trigger rollback.

How to audit an AI-built codebase

Begin by identifying what was generated, what was manually changed and which external services or packages the product depends on. Do not assume the repository is the entire system: prompts may have created database schemas, cloud resources, authentication settings and webhook configuration outside version control. Reconstruct the deployed architecture from evidence, then trace every critical journey through the browser, API, data layer and third-party integrations. Confirm validation, authorisation, state transitions, retries and failure handling before judging code style.

Use static analysis, dependency scanning, secret detection and coverage reports to locate suspicious areas, but never treat a clean scan as approval. Automated tools rarely understand tenant boundaries, payment invariants or acceptable failure behaviour. Pair them with architecture review, manual code tracing and adversarial scenarios. Classify findings by business consequence: exposure of customer data, irreversible corruption, unauthorised actions and inability to recover should outrank cosmetic duplication or stylistic inconsistency.

Architecture decisions founders must explain

Every important capability needs a clear home. The team should know which component owns identity, billing, entitlements, customer records and notifications. When the same rule exists in UI code, an API handler and a database trigger, production fixes become unpredictable. Record system boundaries, data authority and integration contracts. A modular monolith is acceptable when its modules are clear; distributing unclear ownership across services makes the problem harder.

List every external dependency and decide what happens when it becomes slow, unavailable or sends duplicate responses. Timeouts, retries and queues need limits, idempotency and visibility. Database changes should remain compatible during deployment, configuration should be traceable and risky features should have controlled release paths. If each release requires coordinated downtime or an irreversible migration, the prototype is not ready for dependable operation.

Security and privacy beyond scanners

Test access at the server and data layer using accounts from different roles and tenants. Change object identifiers, call APIs directly and test revoked sessions. The question is not whether a login page exists; it is whether every sensitive operation verifies who may perform it on which resource. Inventory credentials and rotate anything that could have appeared in prompts, repositories, client bundles or build logs.

Classify personal and sensitive data, minimise collection and define retention and deletion. Logs must support investigations without becoming an uncontrolled copy of tokens or customer records. Model abuse of account creation, file uploads, password recovery, expensive AI calls and administrative actions. Restrict production access, separate normal support from emergency administration and record privileged actions.

Performance, reliability and cost

Measure complete critical journeys with realistic data volume and concurrency. Include cold starts, cache misses, slow dependencies, background jobs and partial failures. Average response time hides tail latency and concentrated errors, so define user-visible thresholds, acceptable failure rates and the point at which the service should degrade safely. Restore a backup, interrupt a dependency and prove rollback rather than accepting configuration as evidence.

Choose service indicators tied to customer outcomes such as successful payment, completed report or message delivery. Establish targets, alerts and runbooks appropriate to the product stage. Model cloud, database, storage, transfer, observability and inference cost per active tenant or completed workflow. Test how cost changes with large customers and abuse; use quotas, caching, budgets and anomaly alerts before a surprise bill forces architectural decisions.

Build, buy or rewrite

Remediate the current system when core business behaviour is correct, boundaries can be clarified and high-risk defects are local. Replace a component when it cannot enforce a critical invariant, has no recoverable data path or rests on an unsupported foundation. Isolate replacement behind a contract and migrate traffic gradually. This preserves learning and makes rollback possible.

A full rewrite requires stronger evidence: architecture prevents essential security or scale requirements, ownership cannot be recovered, or comparable estimates show remediation is less economical. Define feature parity, data migration, customer continuity and acceptance before starting. Rewriting from frustration produces a second unproven system and delays learning about the first.

A 30-60-90 day readiness plan

In the first 30 days, map the deployed system, freeze uncontrolled changes, rotate exposed secrets and fix launch-blocking identity, data and recovery risks. Establish one dependable deployment path, basic monitoring and a prioritised backlog with owners and acceptance evidence. During days 31–60, add risk-based tests, restore backups, exercise rollback, load-test critical journeys and remove duplicated business rules.

During days 61–90, automate release evidence, practise incident response and close ownership gaps. Review whether remaining debt affects growth, enterprise sales or contractual commitments. The enduring output is not merely an audit report; it is a repeatable engineering operating model that makes production decisions visible, testable and owned.

Founder’s go-live checklist

Before approving launch, require named evidence for tenant isolation, privileged access, payment or entitlement integrity, backup restoration, rollback, critical-journey tests, dependency ownership, alert response and unit cost. Record each item as passed, conditionally accepted or blocking, with an owner and review date. A conditionally accepted risk needs a compensating control and a point at which the product will stop growing until it is resolved.

Also verify operational ownership outside engineering. Support must know how to identify a failed workflow, finance must reconcile revenue-impacting events, and product must control feature exposure. Run one tabletop incident with founders and technical owners. If the team cannot decide who communicates, who restores service and who validates customer impact, the system is not operationally ready even when its code passes review.

Scenario: turning a founder-built prototype into an enterprise-ready product

A founder has validated demand with a rapidly generated SaaS application. Early customers can sign in, upload information and receive an AI-assisted result, but the business now needs team accounts, paid plans and enterprise security review. The audit begins by tracing one tenant from account creation through payment, data ingestion, processing, result delivery and deletion. This reveals where the prototype assumes one user, one workspace or one uninterrupted request. Those assumptions become explicit remediation items rather than surprises discovered during an enterprise pilot.

The engineering team then separates business invariants from implementation preferences. Tenant isolation, entitlement enforcement, payment reconciliation, recoverable data and auditable administrative action are invariants. Framework choice, folder structure and refactoring style are secondary unless they prevent those outcomes. Tests are built around the invariants, including attempts to access another tenant, duplicate billing callbacks, interrupted processing and expired sessions. This gives founders a defensible answer when buyers ask how the product protects data and handles failure.

Operational readiness is tested through a controlled release. The team deploys a backward-compatible database change, enables the revised workflow for internal users, observes technical and business indicators, and rolls back application traffic without corrupting new data. Support receives a runbook for incomplete processing and finance receives a reconciliation view for payments and entitlements. The exercise exposes decision and ownership gaps that a code review cannot find.

The final roadmap separates launch blockers, near-term hardening and scale-triggered investments. The product does not need enterprise complexity everywhere on day one. It does need evidence that critical risks are controlled, ownership is clear and growth will not amplify unknown behaviour. This is also the point at which Project Supply’s Digital Engineering team can move from audit into a bounded remediation programme with acceptance evidence rather than an open-ended rewrite.

Questions to ask the engineering partner

Ask how the team will prove tenant isolation, data recovery, release rollback and ownership rather than whether it follows “best practices.” Request the first ten evidence items it would collect and the conditions that would block launch. Clarify whether the assessment includes deployed cloud configuration, third-party services, database state and operational workflows or only repository code. Confirm who performs architecture, application-security, quality and cloud review and how disagreements become one prioritised decision. The proposal should explain how findings translate into acceptance tests, sequencing and a realistic remediation estimate. Also ask what the partner would deliberately leave unchanged. An expert audit is not a sales mechanism for rewriting everything; it protects working product value while directing investment toward consequences. Finally, require a handover that the internal team can maintain: architecture map, risk register, test evidence, deployment and recovery plan, ownership gaps and review triggers. If the partner cannot describe the go-live decision before starting, the engagement may produce observations without a usable operating outcome.