Replace the feeling of progress with a usable outcome
An MVP can accumulate screens and still fail the task customers pay for. Pick one journey with a beginning and an observable outcome: for example, a customer subscribes, gains the correct access and later cancels without being charged incorrectly. List what prevents that journey from working reliably. Keep cosmetic changes, missing business decisions and engineering defects separate. “Almost done” becomes useful only when the remaining work has explicit acceptance conditions and somebody can demonstrate whether those conditions hold.
When a focused fix is the right choice
A fix is appropriate when the expected behaviour is clear and the defect is local enough to reproduce and correct. An incorrect validation rule may need a small change and regression coverage, not a new framework. Ask the engineer to identify affected callers and explain the expected side effects. If the proposed fix relies on another workaround elsewhere, record that dependency. The size of the patch alone does not determine risk: one changed access-control condition can matter more than a large formatting change.
When refactoring earns its cost
Refactoring is useful when current behaviour has value but the structure makes safe changes unnecessarily difficult. Consider a product with three separate definitions of who has an active subscription. Consolidating the rule can reduce inconsistent decisions, but first capture the intended behaviour for trials, expired subscriptions and payment failures. Otherwise the team may replace three inconsistent rules with one consistently wrong rule. Choose a bounded improvement and state how you will judge it, such as removing duplicate entitlement decisions while preserving the agreed customer flows.
When replacement is justified
Replacement needs a demonstrated constraint: perhaps the current component cannot support the required tenancy boundary, or its dependencies are unsupported and no viable update path exists. Document the constraint and alternatives before approving a rewrite. AWS describes incremental replacement through the strangler fig pattern in its modernization guidance. That is a possible migration approach, not a requirement to adopt microservices or AWS. A small product may need a simpler boundary. Account for data conversion, coexistence, operational ownership and recovery as part of replacement, rather than budgeting only for new feature code.
Illustrative decision record: subscription access
Suppose a billing screen works but access changes behave differently in the API and background jobs. This example is hypothetical. Compare three proposals using the same acceptance criteria. A local patch is attractive if one caller is wrong. Refactoring is more plausible when all callers should share a single rule. Replacement requires evidence that the billing component itself cannot meet the requirement. Before expanding the work, demonstrate one plan against trial expiry, duplicate payment events, failed renewal and cancellation. Use representative test accounts and retain the results.
What to require before funding the next phase
Ask for a short decision record your team can challenge. Estimates should state assumptions and unresolved questions; they are not certainty simply because they appear in a spreadsheet.
- Name the customer journey and the current failure, with a reproduction.
- Compare a local fix, a bounded refactor and replacement against the same requirement.
- Include migration, verification, deployment and recovery in each estimate.
- Set a small first milestone that can prove or disprove the approach.
- Name the person who accepts remaining risk and the evidence required to proceed.
Sources & further reading
Reference material for the guidance and examples above. Where included, community discussions provide context rather than verified incident evidence.
Prepared with AI assistance using the official references below. Worked examples are illustrative, not client case studies. The practical checklists are CodeSignOff editorial guidance, not certification criteria.
About CodeSignOff Editorial
CodeSignOff Editorial publishes engineering guidance for founders evaluating AI-built software. CodeSignOff is a product of Avi Root Info Solutions, led by Shekhar Juneja, whose software career began in 1998 and includes architecture for UK mortgage and credit-rating systems. This organisational byline does not indicate a personal review of this article by Shekhar.
Engineering background and editorial approach · Shekhar’s professional profile ↗
Evidence to take into your own review
Define the code revision and scope. For each finding, record the affected flow, the steps that reproduce it, its business consequence and the evidence for the next action. After a fix, repeat the check and record what remains uncertain. An audit delivers a verdict; remediation and verification are separate steps.
This article is general engineering guidance. It does not establish the security or compliance of your application. Contact us with a correction or a question about the guidance.