Rescue · · 5 min read · Lukas Ceponis

Fix or rebuild a broken AI automation: most repairs are under $4,000

Your automation is broken and you are getting two kinds of advice. One person says it is a small fix. Another says the whole thing has to be rebuilt properly this time. The gap between those answers is somewhere between $750 and $10,000, so it is worth getting right. This is the framework we use ourselves, with the numbers attached.

Fix or rebuild: fix when you can point at the failure

Repair is the right call when the design is sound and the failures are point failures, meaning specific, locatable problems in an otherwise reasonable build. A broken integration is the clearest case. An API changed, a credential expired, a CRM field got renamed; the workflow is fine and one connection needs reattaching, and that is a repair whatever the person quoting you says about the rest of it.

A bad prompt is the second case. The chatbot is wordy, wanders off script, or invents answers because it was never grounded in your documents, and grounding it so the bot stops making things up touches one layer and leaves the rest alone. Missing error handling is the third and the most common in what we have scoped: the design is right but naive, with no retries, no alerts, and nothing to stop duplicate records on a rerun. Those are the failures that kill automations in production, and hardening an existing build takes days.

For scale: we run six production systems ourselves, including a document generator for a hydrogeology client that had produced 168 documents as of August 2026, and almost every problem we have had on them has been a point failure of this kind.

The tell in every one of these: someone can say "this node, this prompt, this webhook" and explain the chain from cause to symptom. If the failure has an address, repair it.

Rebuild when the foundation is wrong

Rebuild when no number of point fixes will converge on a stable system. We see a few foundations broken more than others.

  • A no-code tool pushed past its envelope. No-code platforms are good inside their limits. Once someone has forced one to run multi-step logic with branching state, long loops over thousands of records, or live voice, every fix fights the platform. You know you are here when each patch needs a workaround and each workaround needs its own.
  • No data model. The "database" is scattered across spreadsheet cells, workflow variables, and notes fields with no single source of truth. The same customer exists three times, numbers disagree between systems, and nobody can say which copy is right. Fixing the symptoms of a missing data model produces new symptoms indefinitely.
  • Spaghetti nobody can trace. Dozens of workflows triggering each other, no naming convention, dead branches nobody dares delete. When nobody can explain how one record moves through the system, and the original builder is gone, the cost of understanding the old build starts to exceed the cost of a clean one.
  • The wrong shape. Now and then the thing that was built does not match the job: a nightly batch where the business needed real time, or a chatbot where the customers phone in. There is nothing to repair there.

The numbers

WorkPriceTime
Written diagnostic$500, deducted from any work that follows3 business days
Small fix$750 to $1,5002 to 5 days
Standard rescue$1,500 to $4,0001 to 2 weeks
Rebuild$4,000 to $10,0002 to 4 weeks
Care planfrom $1,500 a monthongoing

All of it carries a 30-day bug warranty. Look at the shape of that table: most fixes land between $750 and $4,000, and a rebuild starts where fixes end. So a rebuild recommendation is a claim that repairing your specific system costs more than $4,000 of effort, and that claim should arrive on paper with reasons attached. "Repairing this means X, Y, and Z, which adds up to more than a clean build" is a judgment you can check. "This is a mess, we should start over" is a mood.

The vendor who always rebuilds

Some shops recommend a rebuild every time, and it helps to understand why. Building new is more pleasant than reading someone else's work, it shows off their preferred stack, and it invoices better. Ask what they found wrong with the current system, specifically; it belongs with the other questions worth asking before you hire an AI agency. A vendor who cannot name the broken foundation has not diagnosed anything, and you would be paying rebuild prices for their comfort.

The mirror image exists. Patching a doomed foundation month after month is also overpaying, only slower. Sometimes the right advice is "stop paying to fix this," and a diagnostic that is never willing to say so is not worth much.

What the written diagnostic has to contain

Whoever you hire, do not accept a verbal verdict. On paper, you want an inventory of every workflow, integration, and data store the system touches, because undocumented systems always contain surprises; a failure list with the cause and severity of each, split into "causing damage now" and "will bite later"; the verdict, fix or rebuild, argued from those findings; and a fixed quote and timeline for the recommended path, so that what sits in front of you is a number.

With that document you can decide calmly, and you can take it to any competent vendor for a second bid. That is the reason a good diagnostic is worth paying for on its own, whoever ends up doing the repair.

The one situation where this framework does not help is a system nobody is using. If the automation broke three months ago and the business kept running, switch it off and cancel the subscriptions; that is the whole answer.

That document is what we sell as the first step. A $500 written diagnostic, delivered within 3 business days, credited in full against the fix or rebuild if you go ahead with us. If you are looking at a broken system and two contradictory opinions, start at our rescue service or send us what you know so far.

Have a system that needs this treatment?