A product can win internal support, secure a launch date, or demonstrate a critical journey while still being unsafe to operate in production. The first signs are rarely dramatic: authentication works until a token expires; a payment or synchronization flow succeeds on the happy path but behaves unpredictably on retry; a small change breaks something elsewhere. The team can run the application, yet cannot say with confidence which configuration, dependency set, data flow, or release artifact is actually in use.
At that point, leadership is often offered a binary choice: keep moving and accept the mess, or stop and rewrite the product. Both can be expensive mistakes. Continuing without containing the risk makes every new commitment depend on behavior the team does not understand. Rewriting indiscriminately discards working behavior, accumulated product knowledge, and the only evidence the team currently has about real users and real operations.
A better question is more specific: for each part of the critical journey, should we keep, repair, isolate, replace, or defer?
What usually sits underneath the visible symptoms
Whether code was generated by AI, written quickly, or inherited may change how it should be reviewed, but it does not tell us whether the system is fit for production. What matters is whether the team can answer questions across several boundaries:
- Behavior: which user journeys are genuinely correct, including failure, retry, timeout, and recovery states?
- Data: which data is the source of truth, who may change it, and what happens during partial failure or migration?
- Security: are authentication, authorization, secrets, dependencies, and sensitive-data handling understood and testable?
- Delivery: can the team reproduce the intended artifact, identify its configuration, release it gradually, observe it, and reverse the change?
- Ownership: who understands the interfaces between critical components and can change them after the original builder or tool is gone?
NIST’s Secure Software Development Framework treats security as part of the development lifecycle rather than a final inspection. CISA’s Secure by Design guidance adds an organizational principle: software producers should take responsibility for customer security outcomes and be transparent about risk. Neither source suggests rewriting unfamiliar code by default. The practical task is to find the missing checks and controls, then gather evidence of how the system actually operates.
Observability is part of that evidence, not a decorative dashboard. OpenTelemetry’s context-propagation model shows why identifiers must cross service boundaries to connect a user action with the work it causes. Without that correlation, an incident becomes an argument among partial views.
The cost of choosing too early
A full rewrite creates a second product before the first has stopped serving users and business commitments. During the transition, the company must understand two implementations, protect data, decide which system owns each behavior, and keep a way back. The target architecture may be cleaner while the migration itself remains the riskiest part of the project.
Keeping everything is not neutral either. New features continue to rely on unverified assumptions, making the problem harder to isolate later. Delay becomes more expensive as more users, data, integrations, and commitments begin to depend on a component the team cannot explain.
This is an editorial conclusion, not an industry benchmark. A practical measure is how many new commitments will depend on the uncertain component before the decision is reviewed again.
The five-way decision map
This is DSL’s editorial framework for recovery. A single product journey may need several of these paths at once.
Keep
Keep a component when its important functions behave predictably and can be tested, its security and data handling meet the current requirements, and someone is responsible for it. “Old,” “generated,” or stylistically inconsistent are not sufficient reasons to remove working code.
What to verify: the critical journey can be repeated with the expected result, the build can be reproduced, the production outcome is visible, and an owner is named.
Repair
Repair a component when it performs useful work and is contained well enough to fix independently, but a specific weakness makes operation unsafe—for example, broken authorization, retries that can duplicate work, unpinned dependencies, or missing failure tests.
What to verify: the fault is contained, the fix can be tested independently, and the rest of the system does not need to migrate with it.
Isolate
Isolate a component when the product still needs it, but it is too opaque, privileged, or fragile to change safely. Restrict its permissions, data access, network routes, and interfaces; add tests and telemetry at the boundary; prevent new features from depending on it directly.
What to verify: the team can limit the potential impact, observe every critical interaction, and avoid increasing the system’s dependence on the component.
Replace
Replace a component when it repeatedly prevents the product from meeting an important requirement, its security or data behavior cannot be verified, no one can regain enough knowledge to own it, or its constraints conflict with the way the product must operate. Start with a clear interface and cutover plan, not a new repository and a hopeful calendar.
Microsoft’s Strangler Fig guidance supports staged replacement: identify boundaries, route selected behavior to the new implementation, validate outcomes, and remove the old path only after the new one is proven. It preserves rollback during transition while acknowledging the temporary cost of operating both paths.
What to verify: the team has defined how traffic or behavior will move, how data will be checked, who takes responsibility, and when to roll back.
Defer
Defer work on a component when it sits outside the critical journey, changing it now is riskier than leaving it, and the team can stop new work from depending on it. Record why the decision was deferred, who is watching it, and what event should reopen the question.
What to verify: the product can meet its current commitment without changing the component, no new dependencies are being added, and the review condition is recorded.
What to verify in the first five to seven days
The first week should reduce uncertainty, not produce a speculative rewrite estimate.
- Name one business commitment and one critical journey. A launch, customer obligation, due-diligence question, reliability threshold, or data migration is more useful than “clean up the codebase.”
- Trace the journey and its state. Map client behavior, APIs, storage, asynchronous work, third parties, identity, permissions, configuration, and the final observable outcome.
- Reproduce the delivery path. Identify the source revision, dependencies, secrets and configuration boundaries, build artifact, deployment steps, environment, and rollback route.
- Exercise failure deliberately. Test timeout, retry, duplicate request, stale state, permission denial, partial completion, and recovery—not only the demo path.
- Build an operational trail. Make the journey traceable across components, record the product version, and define the signals that distinguish a safe change from a regression.
- Classify and sequence. Assign keep, repair, isolate, replace, or defer to the reviewed components; contain material risk first, then sequence recovery around the business commitment.
Google’s SRE guidance on canary releases reinforces the final step: expose a new version to a limited population, decide in advance how it will be evaluated, and use the result to continue, pause, or roll back. “We can release it” should mean both that deployment is technically possible and that the team can test the change safely with limited exposure.
When an external assessment is justified
An external assessment is useful when ownership is fragmented; a launch, transaction, or other important milestone needs evidence the team does not produce; security or data-integrity boundaries are unclear; or several credible plans cannot be compared using the same criteria.
It is less useful when leadership wants validation of a preferred architecture without exposing operating constraints, or no owner can act on the findings.
The result should be a decision-ready picture, not a generic quality score: what business goal is at risk, what evidence was reviewed, which risks need immediate containment, what to do with each critical component, in what order to proceed, and how success will be checked.
Recommendation: before approving a rewrite, apply the map to one critical journey. If the team cannot gather the necessary evidence within a week, assess the system and build a recovery plan before making another major delivery commitment.
Technical notes and primary sources
- NIST SP 800-218, Secure Software Development Framework — lifecycle practices for producing better-secured software and responding to vulnerabilities.
- CISA, Applying Secure by Design Thinking — ownership, transparency, and leadership principles behind Secure by Design.
- Microsoft Azure Architecture Center, Strangler Fig pattern — incremental replacement, transitional boundaries, validation, and rollback considerations.
- Google SRE Workbook, Canarying Releases — limited rollout, evaluation, monitoring, and rollback as release controls.
- OpenTelemetry, Context propagation — correlating traces, logs, and metrics across process and service boundaries.
A focused next step
DSL’s AI Product Recovery engagement begins with a paid assessment of the product’s current state. The starting point is one critical journey, the production requirement it must meet, and the question the team cannot yet answer. The assessment shows what can stay, what needs repair or isolation, and what genuinely needs replacement. It also produces an evidence-based order for the first recovery steps. Only then can the remaining implementation be scoped responsibly.