A developer can explain the critical path
Core workflows, data writes, dependencies, and access checks are visible enough to reason about and test.
Repair vs. Rebuild an AI App
Keep what earned trust. Replace what cannot support the product.
Do not rebuild because the code looks unfamiliar, and do not keep it because the demo works. Compare the current foundation, production risks, remaining product scope, and total cost of change.
The direct answer
Should an AI-built prototype be repaired or rebuilt?
Repair when the important boundaries—identity, authorization, state, data ownership, deployment, and dependency choices—can be understood and trusted, and when the remaining work is narrower than replacement.
Rebuild the affected foundation when the system cannot enforce access correctly, preserve data consistently, be tested or deployed safely, or be owned without hidden dependencies. Often the best answer is partial replacement: keep a validated interface or workflow while replacing the backend seam that creates the risk.
“AI-generated” is not a diagnosis. The implementation and operating evidence decide the path.
Decision framework
Five paths, each with a different reason.
| Path | Evidence that supports it | Primary tradeoff |
|---|---|---|
| Keep and extend | Clear ownership, understandable structure, correct core behavior, appropriate access boundaries, repeatable deployment, and a manageable gap to launch. | Preserves momentum, but still requires discipline around tests, documentation, and production operations. |
| Repair in place | Problems are isolated and testable: specific defects, missing failure states, weak observability, configuration issues, or bounded security gaps. | Fastest when scope stays bounded; expensive if every fix uncovers another coupled failure. |
| Replace a seam | The interface or business workflow is useful, but auth, data access, payments, an integration, or deployment cannot be trusted. | Preserves validated product work while introducing temporary integration and migration complexity. |
| Rebuild the foundation | Core state is inconsistent, access cannot be enforced, ownership is unclear, dependencies are unmaintainable, or change and release risk are pervasive. | Creates a cleaner base but risks redoing useful behavior and delaying market learning. |
| Validate first | The target user, problem, workflow, or willingness to adopt is still uncertain. | Defers engineering investment; requires focused user and market evidence instead. |
Avoid sunk-cost reasoning in both directions
Existing effort is not a reason to preserve a harmful foundation. A developer's preference for a different stack is not a reason to discard useful, ownable software. Compare future cost, risk, and learning.
Signals to repair
The foundation can support a controlled next stage.
Failures have clear boundaries
The risky part can be corrected or replaced without destabilizing unrelated product behavior.
Accounts, code, data, and releases can transfer
The business can control the repository, providers, domain, data export, configuration, and deployment path.
Critical behavior can be verified
Acceptance scenarios and targeted automated checks can protect the repaired workflow from regression.
The architecture fits the first release
The system does not need to solve hypothetical scale, but it can safely support the intended users, data, and consequence.
The gap is narrower than replacement
The cost to close production blockers and near-term product needs is lower than rebuilding and revalidating the same behavior.
Signals to rebuild or replace a seam
The current foundation makes important promises impossible to trust.
One signal does not automatically require a full rewrite. First test whether the problem can be isolated behind a safer boundary.
Authorization cannot be enforced reliably
User or tenant data boundaries live only in the interface, are inconsistent, or cannot be verified without touching many unrelated paths.
Core data has no dependable source of truth
Writes conflict, schemas drift, business rules disagree, or the product cannot explain which state is authoritative.
Every release is manual and unreproducible
Environments, configuration, dependencies, and deployment steps cannot be recreated or rolled forward safely.
The business cannot control critical assets
Source, hosting, domain, provider accounts, data export, or essential services depend on inaccessible or personal ownership.
Small changes require system-wide risk
Tight coupling and absent tests make every modification unpredictable, so repair cost compounds without reducing uncertainty.
The prototype architecture solves the wrong problem
The real product now needs a different identity, data, offline, integration, transaction, or operating model than the demo assumed.
1. Preserve the current state
Before changing anything, confirm source access, export or snapshot what matters, record the current deployment, and avoid rotating or moving credentials without an ownership plan. The goal is a safe point of reference—not a promise that the current state is recoverable until restore is tested.
2. Inventory product and operating dependencies
List the user surfaces, repository, environments, database, storage, model providers, APIs, email or SMS, payments, analytics, domain, accounts, and owners. Mark each fact as observed, reported, or unknown.
3. Exercise critical workflows and boundaries
Walk through normal use, incorrect input, duplicate actions, permission changes, interrupted requests, integration failure, and recovery. Review server-side access, secrets, data movement, logs, deployment, and backup evidence in proportion to risk.
4. Estimate repair and replacement against the same release
Define the same target user, workflow, security needs, data migration, integrations, and operating requirements for both paths. Otherwise a narrow repair estimate will be compared with an inflated rebuild wishlist—or the reverse.
5. Stage the recommendation
Separate immediate safety and ownership work, production blockers, first-release scope, and post-launch improvements. A partial replacement should include the transition seam and data migration or cutover plan.
Decision artifact
A useful assessment ends with evidence, unknowns, risk priority, keep/repair/rebuild boundaries, assumptions, a staged scope, and the information required for a credible price and timeline.
Cost and process guidance
Price the release and its risk—not the number of generated screens.
A visual prototype can represent a small or large production scope. Cost follows users, data, integrations, consequence, migration, operating requirements, and remaining uncertainty.
Define the release before pricing it
Name the first users, critical workflows, included systems, migration, security and operating requirements, client dependencies, and acceptance criteria.
Sequence dependencies and risk
A credible schedule starts after the release boundary, access, review findings, and outside dependencies are clear. Provider access, data work, and approvals can control the critical path.
What drives a production quote
Users and workflows
Roles, onboarding, account recovery, collaboration, administration, edge cases, accessibility, and the number of critical journeys.
Consequence and obligations
Sensitivity, tenant boundaries, retention, deletion, migration, audit needs, model exposure, and specialist review.
Outside systems and transactions
API quality, webhooks, payments, email or SMS, identity providers, rate limits, failure handling, and test environments.
Environments and release operations
Hosting, automated checks, deployment, monitoring, error response, backups, recovery, analytics, and documentation.
Migration and coexistence
Moving users or data, preserving URLs, running old and new systems together, cutover, rollback, and communications.
Unknown code and ownership
Missing source, unclear credentials, undocumented providers, absent tests, and unverified assumptions require discovery before a fixed scope is responsible.
Ask for an assumption-based scope
A quote should name the intended release, included and excluded work, client dependencies, third-party costs, ownership, acceptance criteria, support boundary, and what happens when an assumption proves false.
FAQs
Repair, rebuild, cost, and timeline questions.
Should AI-generated code always be rewritten?
No. Decide from observed behavior, security boundaries, data integrity, testability, maintainability, ownership, and future change cost—not simply from whether AI helped create it.
How much does it cost to productionize an AI app?
There is no responsible universal price. A credible quote follows a review of users, data, integrations, security, migration, operations, and the first-release boundary.
How long does productionizing take?
The schedule depends on the production review and defined first release. Data work, outside providers, approvals, security, mobile requirements, and complex integrations can control the critical path.
Can we keep the interface and rebuild the backend?
Often, yes. A partial replacement can preserve validated user experience while replacing authentication, data access, integrations, or deployment foundations. Feasibility depends on coupling and ownership.
What do you need before quoting?
The intended first release, users and roles, data, critical workflows, repository and deployment access if available, integrations, ownership, migration needs, launch constraints, and the largest unresolved risks.
Related resources
Collect the evidence before choosing.
AI prototype review
Choose the path before funding the build.
Bring the prototype, repository if available, intended user, data, integrations, ownership, and launch constraints. The goal is a keep, repair, replace, rebuild, or validate-first recommendation.
Request a Fit CallA scoped assessment may be required before a build quote.