Rebuild or Retrofit? What to Do When Your Prototype Fails a Security Review

Your prototype failed a security review. You have three realistic options: retrofit the existing code with the missing security and compliance layer, rebuild it on a governed platform using the prototype as your spec, or retire and fence it as an internal, non-sensitive tool. This guide walks the triage in order: contain the immediate risk, read the findings correctly, then decide.

One reframe before the checklist, because it changes how you make every decision below: the prototype was not a waste. It was requirements discovery. You now know the data model, the roles, the workflows and the screens your users actually need, which is knowledge most projects spend months acquiring. The question is not “how do we save the code.” It is “where should what we learned live now.”

Contain First: The Same-Week Checklist

Before any rebuild-versus-retrofit debate, close the doors the review found open. None of this requires a decision about the app’s future.

• Take the app off the public internet if it holds real data. Many AI build tools deploy public by default, and misconfigured sharing settings are one of the most common findings in this class of app. Private, allowlisted or offline until further notice.
• Rotate every secret. API keys, database credentials, tokens in client-side code or commit history. Assume anything the review flagged as exposed is compromised.
• Stop new sensitive data from entering. If the app collects anything regulated (health, financial, minors’ data), pause intake now. The gap grows with every record.
• Snapshot the evidence. Export the data, the schema and any access logs before you change anything. You may need them for disclosure obligations, and you will need the schema for whichever path you choose.
• Tell the reviewer what you did. Security reviewers and procurement teams respond well to fast containment. It buys you time to triage properly.

Read the Review Findings Correctly

Not all findings are the same kind of problem, and the split determines which path is even available to you. Sort every finding into one of two buckets.

Artifact Flaws: Problems in the Code

Injection vulnerabilities, missing input validation, secrets hardcoded into the source, broken authorization checks on individual endpoints. These are defects in the artifact the AI generated. They are real, they are common, and they are fixable by engineers, one finding at a time.

They are also well documented at scale. Escape.tech scanned 5,600+ publicly available vibe-built apps and found 2,000+ high-impact vulnerabilities, 400+ exposed secrets and 175 PII instances including medical records. That is what a scan of this app class looks like, and it is why your review found what it found.

One caution before you plan to prompt your way out: regeneration does not converge on secure. Veracode’s Spring 2026 benchmark found AI secure-generation rates flat at roughly 55 percent despite two years of capability gains (reasoning-focused models do better, at 70 to 72 percent, which still means roughly three in ten generation tasks introduce a known flaw). As Veracode’s Felix Brombacher put it: “Models have become excellent at writing code that compiles. They’ve failed at writing code that’s safe.” Fixing artifact flaws is engineering work, not prompting work.

Boundary Flaws: Problems in What Surrounds the Code

No Business Associate Agreement covering the data. No audit trail. No access model beyond “logged in or not.” Default-public infrastructure. No documented risk analysis. These findings are not about the code at all. They are about the boundary the code lives inside, and no amount of patching individual endpoints creates a boundary that was never there.

This is the distinction that decides your path. Artifact flaws can be remediated in place. Boundary flaws are architectural: the platform that generated your application either provides a governed boundary (roles, record-level security, audit, compliance agreements) or it does not, and if it does not, a retrofit means building that entire layer yourself, by hand, and maintaining it forever. The deeper taxonomy is covered in our companion piece on code artifacts vs. governed platforms.

If your findings are boundary-shaped, first verify what your build tool actually offers today, because vendor postures change and marketing language is not a compliance instrument. We keep dated, sourced verdicts current for the major tools: Is Lovable HIPAA-Compliant?, Is Replit HIPAA-Compliant?, Is Bolt HIPAA-Compliant?

The Decision Framework

Score your situation across six signals. The column with the most checks is your default path; regulated data overrides everything else in its row.

Two honest notes on reading the table. First, mixed findings usually resolve to the boundary column: if you have both, fixing the injection bugs still leaves you without an audit trail or a BAA. Second, “retire or fence” is a legitimate outcome, not a failure. Plenty of prototypes should live out their days as a useful internal tool while the sensitive workflow moves somewhere governed.

RULE OF THUMB: If regulated data (PHI, financial data, government records, or sensitive personal information) is involved, default to Rebuild. Compliance and governance requirements outweigh most other considerations.

The Retrofit Path, Honestly

Retrofitting means keeping the artifact and building the missing layer around and into it. Done properly, for an app that must pass a real review, it includes:

• Remediating every artifact flaw, with regression tests so fixes hold through future changes
• Designing and implementing a real access model: roles, permissions, row-level rules
• Adding audit logging that a reviewer will accept
• A documented risk analysis, penetration testing, and staff security training
• For regulated data, the legal layer: agreements such as BAAs with every vendor in the data path
• Repeating the process work annually, because reviews recur and evidence expires

Retrofit is the right call when the data is not regulated, the gap is mostly artifact flaws, and you have engineers who genuinely accept ownership of the code, not just this quarter but as a standing responsibility.

When the data is regulated, price it before you commit. A regulated retrofit is not a sprint; it is a project with a recurring annual tail, because the process work, training, penetration testing, and risk analysis, repeats every year and the evidence expires. And getting the boundary wrong is expensive: according to IBM’s 2025 Cost of a Data Breach Report, healthcare data breaches average $7.42 million per incident, the highest of any industry for the 14th consecutive year.

None of that proves rebuilding is cheaper in your case. What it does establish is that a regulated retrofit is a project with consultancy-scale costs and a recurring annual tail, not a sprint, and that anyone who quotes you a weekend and a scanner license is not describing the same work. The pattern is familiar from the free-tier era: the prototype was priced, the product was not. We cover that structure in the hidden cost of “free” AI app builders.

The Rebuild Path, Honestly

Rebuilding does not mean starting over. It means treating the prototype as the most detailed spec your team has ever written, and moving it onto a platform where the boundary your review demanded already exists.

The method:

• Inventory the data model. Export the schema and data from the prototype. Every table, field and relationship is validated requirements.
• Inventory the roles. List every user type and what each one may see and do, including the distinctions your prototype fudged (that fudging is probably a finding on your review).
• Inventory the workflows. The forms, reports, approvals and notifications users actually used. Cut the ones they did not; the prototype told you.
• Rebuild where governance is inherited. On a governed platform, roles, record-level security, encryption and audit logging are properties of the platform, not features your team writes. The rebuild is configuration and interface work against a spec you already have, which is why rebuilds of a working prototype are typically measured in weeks, not quarters. Whether that holds for your application depends on its complexity; a rebuild is not automatically cheaper or faster, it is differently shaped: subscription plus configuration instead of engineering payroll plus an annual security process.

The honest tradeoffs run the other way too. You operate within the platform’s capabilities rather than owning arbitrary code, and the platform relationship is ongoing. For teams whose review failed on boundary flaws, that is precisely the point: the boundary is what you are buying.

Caspio is built for this path. It is an application platform where AI accelerates the build and the result is a native app on governed infrastructure, deployed as a complete Caspio-hosted application or as embeddable apps and components, with roles, record-level security, and audit built in and unlimited app users. For regulated workloads, the formula matters: AI builds it; the platform it lives on runs a HIPAA-compliant environment with a signed BAA and completes annual independent SOC 2 Type II audits. That audit is independent and renewed annually, which is the evidence class security reviewers ask for by name. Pricing is flat rather than per-seat. For teams handling PHI, HIPAA coverage is a $500 per month add-on on a Team plan or higher, with a one-year term; HIPAA-enabled totals start from $800 per month.
If your prototype lives in a prompt-to-code tool and you are surveying where to take it, see LLovable alternatives and the full buyer’s guide to AI app builders for regulated industries.

The Retire-or-Fence Path, Honestly

Sometimes the best answer is to stop trying to make the prototype something it is not.

Fencing means: strip the sensitive data and the regulated workflow out of the app, park it behind your SSO as an internal tool for a known group, and move the sensitive workflow to a governed system. The prototype keeps doing the low-stakes work it does well: a calculator, a tracker, an internal dashboard over non-sensitive data. The findings that failed your review mostly stop applying, because the data they threatened is gone.

Retiring means shutting it down entirely, keeping the schema and workflow inventory as the spec for whatever replaces it.

Choose this path when nobody can own the code, the sensitive workflow is separable, and the fastest risk reduction is removal. There is no shame in it. A prototype that discovered your requirements and then retired paid for itself.

Bring the Findings, Not a Decision

If you are mid-failure right now, you do not need a sales pitch. You need a second set of eyes on the findings.

Caspio’s team will do a rescue assessment with you: bring the security review findings and the prototype, and work through the classification above to see which path actually fits, including the cases where the answer is “retrofit it” or “fence it.” If rebuild is the fit, you can validate it yourself on a 14-day free trial, with 24×7 human support from real engineers along the way.

Frequently Asked Questions

Can a vibe-coded app pass a security review?

Sometimes. If the findings are artifact flaws (injection, exposed secrets, endpoint authorization bugs) and engineers remediate them properly, the app can pass. If the findings are boundary flaws (no BAA, no audit trail, no access model, public-by-default infrastructure), passing requires building an entire governance layer around the artifact, which is a far larger project than fixing the code. Re-prompting the AI is not a remediation path: AI secure-generation rates have stayed flat at roughly 55 percent despite capability gains (Veracode, Spring 2026).

How much does it cost to make a prototype HIPAA compliant?

There is no market-wide number, but the stakes are clear: according to IBM’s 2025 Cost of a Data Breach Report, healthcare data breaches average $7.42 million per incident, the highest of any industry for the 14th consecutive year. A regulated retrofit is also a project with recurring annual process work, training, penetration testing, and risk analysis, not a one-time fix. The alternative most regulated teams evaluate is rebuilding on a platform where HIPAA coverage and audit controls are inherited rather than constructed.

Is rebuilding faster than retrofitting?

Not categorically, and be suspicious of anyone who says otherwise without seeing your app. The honest pattern: retrofits are engineering projects whose regulated versions carry consultancy-scale budgets and annual recurring process work, while rebuilds of a working prototype on a governed platform are typically configuration-and-interface projects measured in weeks, because the security layer already exists. Which is faster for you depends on your findings mix, your app’s complexity, and whether you have engineers who can own the artifact.

Do I have to throw away my prototype?

No, and you should not. Even in a full rebuild, the prototype is your validated spec: the data model, roles, and workflows it contains represent requirements discovery that normally takes months. Export the schema, inventory the roles and workflows, and carry them into whichever path you choose. The only thing you may be discarding is the code, and only when nobody can responsibly own it.