When to rebuild
vs when to patch.

Three signs a patch is the right call.

Patching makes sense when the build's core logic is still correct and the gap between what it does and what you need is specific and contained.

• The problem is one thing. "It doesn't handle PDF attachments" or "the pricing it uses is eighteen months out of date." One problem, one fix. A good builder can tell you the scope of a patch in under an hour.
• The underlying workflow hasn't changed. You still do the same kind of work in the same way, with the same tools. What changed is the content — the data, the pricing, the service list — not the shape of how work flows through your business.
• The build is less than two years old and has been maintained. A build that received regular small updates throughout its life is in better shape than one that has run untouched for twenty months. Regular maintenance means someone has been reading the code recently and knows where things stand.

Four signs a rebuild is the right call.

• Your business changed substantially. Different services. A different client type. A different team structure. If someone asked you to write the workflow description today and it looked nothing like the one that scoped the original build, you are asking an automation built for a different business to serve your current one.
• The patches have started to pile up. Three patches on top of the original build, each one added to work around a limitation of the last. The logic is now spread across multiple versions of thinking. Nobody — including the original builder — can hold the whole thing in their head at once. This is the clearest signal a rebuild will cost less over the next two years than continued patching.
• The tools underneath have been superseded. The AI model your automation was built around is now two generations old. The integration it uses to connect to your email was deprecated last year and is being held together by a compatibility layer. The foundations have moved. Patching the behaviour is harder than rebuilding on the current foundations.
• It would take longer to explain the existing build to a new developer than to scope a fresh one. Ask your builder to estimate both. If the explanation cost exceeds the rebuild cost, the answer is clear.

What a rebuild is not.

A rebuild is not starting from scratch with no information. Eighteen months of running an automation is eighteen months of data about what works, what breaks, and what your business actually needs. A rebuild that ignores that learning would be wasteful.

A good rebuild starts from today's workflow description — the one you would write if you were hiring a builder for the first time right now — and carries forward only the specific things you know from running the first build. Integrations that worked well. Edge cases that kept coming up. Outputs you know your clients respond to.

Rosie · Solo nutritionist — her first build was scoped around one-to-one clients. Eighteen months later, half her work was group programmes. Rather than patch the one-to-one automation to handle groups as a special case, she rebuilt it around the current reality. The rebuild took three weeks. Patching, her builder estimated, would have taken five and never worked quite right.

How to have the conversation with your builder.

Ask your builder to give you a written comparison: what a patch costs in time and money, what a rebuild costs, and what the expected lifespan of each outcome is. That last part matters. A patch that buys you six months is a different proposition from a patch that buys you two years.

A good response sounds like:

“Honestly, rebuild. The core logic is sound but the business it was built for is different now. A patch gets you another six months. A rebuild gets you two years and costs about the same as three patches would.”

A response worth questioning sounds like:

“I'd recommend a rebuild. It'll be a full project from scratch, probably eight weeks.”

The second answer might be right. But a builder recommending a full rebuild without first showing you the patch option and explaining why it falls short has an obvious financial interest in the recommendation. Ask for the comparison.

Red flags.

• A builder recommends a rebuild without offering a patch estimate first.

  The comparison should exist before the recommendation. If only one option is presented, ask for the other. You need both numbers to make a sensible decision.

• The patches have no written scope.

  Small patches that are agreed verbally and billed by the hour accumulate quietly. After six patches you may have spent more than a rebuild would have cost, with nothing to show for it but a build that is harder to understand than it was.

• A rebuild proposal does not reference what you learned from the first build.

  A proposal that reads as if the first build never happened is a proposal written for a general client, not for you. The first build is worth something. A good rebuilder uses it.