Rewrite or Harden? How to Triage an AI-Built Store

Your AI-built store got you to launch. Orders are coming in. Then something small breaks: a discount stacks when it shouldn't, a stock count drifts, a customer sees another customer's order history. Someone says the words nobody wants to hear: "we may need to rebuild this."

That sentence is where many founders lose months. A full rewrite throws away the parts that work and resets a timeline you can't afford. A pile of patches keeps the parts that don't. The right answer is almost never the whole store. It is a decision made one component at a time.

Why AI-built stores need a decision, not just a fix

Two 2026 datasets explain why these codebases get harder to repair the longer you wait.

Veracode's Spring 2026 GenAI Code Security Update, published March 24, 2026, tested flagship models on 80 coding tasks across Java, JavaScript, C# and Python. Only 55% of tasks produced secure code, even though syntax correctness exceeded 95%. Cross-site scripting tasks passed just 15% of the time. The code looks right and runs. It is the safety logic that is missing.

GitClear's analysis of 623 million changed lines shows what happens to structure. Refactoring-type "moved" code fell from 21% of changes in 2022 to 3.8% year-to-date in 2026, while duplicate code blocks rose from 40.3 in 2023 to 73.0 in 2026, an 81% increase. When a tool adds code instead of reorganising it, the same business rule ends up written in several places.

For a store, that matters in a specific way. If your tax, discount or shipping rule lives in four files, fixing it in one leaves three wrong copies. The question is not "is the code bad?" It is "can this component be made correct without rebuilding it?"

Direct answer: when to harden and when to replace

Answer in brief: Harden a component when its data model and business rules are sound and the gaps are missing controls such as validation, authentication, tests and monitoring. Replace it when its data model or state logic is wrong, or the same rule is duplicated across files, because fixing it means rewriting it anyway. Decide component by component, never store-wide.

The three-question triage

Score each component of the store on three questions. Do it on a whiteboard; it takes an hour.

1. Exposure: what is the worst thing this component can do?
Components that touch money, personal data or legal obligations carry the most exposure: checkout, payments, authentication and permissions, order and inventory state, tax calculation. A broken product carousel is annoying. A broken payment confirmation is a loss event.

2. Soundness: is the foundation right?
Open the data model. Are orders, line items, payments and inventory modelled as separate records with clear states, or are they one loose table with flags? Is each business rule written once? A sound foundation with missing controls is a hardening job. A wrong foundation is a replacement job, because every control you add sits on top of the same flaw.

3. Evidence: can you prove it works?
If there are no tests and no logs, you can't tell whether a fix worked. Adding tests around a component is the cheapest way to learn its real condition. If the component can't be tested because everything is entangled with everything else, that is itself a signal to replace it.

What usually gets hardened

Most storefront surface area survives triage. Catalog display, content pages, search result rendering, account pages and simple admin views are usually sound enough. The work there is controlled and unglamorous: input validation, rate limiting, security headers, dependency review, error handling, accessibility fixes, and a test suite that pins current behaviour before anyone touches it.

Hardening has a real advantage: you keep every feature your customers already use, and you can ship improvements as small, reviewable changes instead of one big-bang cutover.

What usually gets replaced

Four components are the usual candidates, because they are where AI-generated code tends to encode a shortcut as if it were a rule:

• Checkout and payment confirmation. If the server trusts what the browser reports about price or payment status, the flaw is architectural. Replace it with server-side price calculation and payment verification.
• Authentication and authorisation. Access checks scattered across individual pages, rather than enforced in one place, are cheaper to rebuild than to chase.
• Order and inventory state. If stock is a number overwritten from several places, you need a proper state model, not a patch.
• Tax and compliance logic. Duplicated, hard-coded rules will drift. Centralise them behind one tested module.

Replacing a component is not replacing the store. A well-run replacement swaps one component behind a stable interface while the rest keeps trading.

A sequence that protects revenue

At MnT Future, the order we work in follows exposure, not convenience. It is the same approach behind AI cleanup for AI-built stores and our AI Cleanup Lab build:

1. Freeze and observe. Add logging and monitoring first, so you can see failures you currently can't.
2. Pin behaviour with tests. Write tests that capture what the store does today, including the bugs you know about.
3. Close the highest-exposure gaps. Payments, authentication, secrets and data access come before anything cosmetic.
4. Replace the components that failed the soundness test, one at a time, behind the existing interfaces.
5. Harden the remainder and add continuous integration so the problems don't return.

The honest caveat: there are cases where a full rebuild is correct. If the data model is wrong across the board, or the codebase can't be tested at all, hardening is a more expensive way to arrive at a rewrite. A real assessment should be able to tell you which situation you are in, with component-level reasoning, before anyone quotes a price.

FAQ

Can an AI-built store be fixed instead of rebuilt?

Often, yes. Components with a sound data model and missing controls can be hardened. Components with a wrong data model or duplicated business rules are usually cheaper to replace.

What should be fixed first in a vibe-coded store?

The highest-exposure components: checkout and payments, authentication and access control, secrets handling, and data access. Add logging and tests before changing them.

How do I know if my store is ready to scale?

Look for tests, monitoring, server-side validation of prices and payments, and each business rule defined once. If any of these are missing, treat the store as not yet production-ready.

Next step

If you have an AI-built store and aren't sure which side of the line your components fall on, book a free strategy session with MnT Future. We'll walk through the triage with you and tell you plainly whether the honest answer is harden, replace, or leave it alone.