← All posts
AI rescueJune 10, 2026 · 9 min read

How to tell if your AI-built app is worth saving

KFKevin FrickePresident, Lone Star Media

A 12-point triage checklist for AI-built apps: score auth, payments, data integrity, and maintainability yourself before you pay anyone for a rescue — or a rewrite.

Salvage is a decision, not a vibe

Some AI-built apps are rough but worth keeping. Some are a demo that accidentally met customers. The expensive mistake is treating those as the same project.

This checklist is the one we run before we recommend rescue, partial rewrite, or a clean rebuild. You can score it yourself in an afternoon. Be honest. The point is clarity, not optimism.

How to use it: give each item a 0 (no / unknown), 1 (partial), or 2 (solid). Totals at the end. Unknown counts as 0 — "we think it's fine" is not evidence.

The 12-point triage

1. Can someone explain the core path end to end?

Pick your money path or your login path. Can a human walk from click to database write without guessing? If the only explanation is "ask the chat history," that is a zero.

2. Do you have a real source of truth for the code?

One primary repo, a clear main branch, and deploys that come from it. Multiple zips, "final_v3_really," or production edited by hand in a panel is a rescue tax you will keep paying.

3. Are secrets handled like secrets?

No API keys in the client bundle, no shared "admin" password in the README, no production credentials in a public or semi-public chat log. If you are unsure, rotate and assume you need a 0 until proven otherwise.

4. Auth: who is the user, really?

Sessions or tokens should be verifiable server-side. Role checks should live in one place. "The UI hides the button" is not authorization.

5. Money paths are boring and verified

If you take payments, you need webhook verification, idempotent handling, and a way to reconcile provider state with your own records. Happy-path demos fail on the first retry, refund, or double-submit.

6. Data integrity beats UI polish

Can you trust unique constraints, foreign keys, and migrations? Or did the model invent a schema that only works with the seed data from last Tuesday?

7. Environments are named and separate

Local, staging, production — different databases, different secrets, a way to promote intentionally. One environment that everyone calls "prod-ish" scores low.

8. Observability exists when things break

You can answer "what errored in the last hour?" without SSHing in panic. Logs, basic error tracking, and timestamps beat screenshots of a red console.

9. Dependencies are intentional

Lockfiles committed, install reproducible, no mystery packages added "because the model said so." You do not need a perfect supply-chain program; you need to know what you ship.

10. Tests cover the scary parts — or you can add them

Zero tests is common. The question is whether the code is structured enough to test auth, billing, and data writes without a full rewrite. If every function is a 400-line tangle with hidden globals, salvage gets harder.

11. The product still matches the business

Are customers paying for what the app actually does well? Sometimes the codebase is messy but the wedge is clear. Sometimes the code is fine and the product isn't. Don't spend rescue money on the wrong problem.

12. You can pause feature work

Rescue needs a freeze on shiny new features long enough to stabilize. If the business cannot pause, plan a parallel clean path for the critical flows instead of "fixing while shipping."

Scoring

18–24: Strong salvage candidate. Stabilize, add tests around the dangerous surfaces, and keep building on what you have.

10–17: Conditional salvage. Expect a focused rewrite of auth, payments, or data layer while preserving the product shell and customer relationships.

0–9: Treat a full or near-full rebuild of the critical path as the default. Keep the old system only as a bridge if customers depend on it.

A low score is not a moral failure. It is a map. Many good businesses started on code that would not pass this list — and then paid to make it honest.

What "worth saving" usually means

Worth saving rarely means "keep every file." It means keep the customer relationships, the domain learning, and the parts of the system that already encode real edge cases. Throw away the decorative complexity the model added because it sounded enterprise.

If you want a second set of eyes, AISlop.Surgery starts with triage and a written plan. You can stop after the diagnosis. That alone is often enough to decide.

Keep reading.