When to rebuild custom software instead of patching it

"Just one more patch" is a reasonable call most of the time, which is exactly why it's easy to keep making it past the point where it's still true. The signs that a rebuild is actually the cheaper option are visible before the system fails; they just don't look urgent on their own.

Every new feature breaks something unrelated

If adding a feature in one part of the system now reliably breaks something in a different, seemingly unconnected part, the codebase has accumulated hidden coupling that a patch can't fix, because the problem isn't the new code, it's everything the new code touches.

Nobody on the team fully understands how it works anymore

A system that only one person, or nobody, can confidently explain end to end isn't a documentation problem you can write your way out of. It's a sign the system has outgrown the mental model it was built on, and every change from here is a guess informed by testing in production.

The technology it's built on is no longer actively maintained

Security patches that stop arriving, a framework with no community left to ask, or a language version nobody supports anymore turns every future change into a bigger risk than the change itself justifies. This is the clearest, most objective sign on this list, because it doesn't depend on opinion.

Patch cost per feature keeps rising while feature size keeps shrinking

If delivering smaller features now takes longer than delivering bigger ones used to, that's not a team capacity problem, it's the codebase. Tracking this over a few quarters, rather than feeling it anecdotally, makes the case for a rebuild concrete instead of a hunch.

A rebuild doesn't have to mean starting from zero

A full rebuild is the expensive, risky version of this decision. The more common and lower-risk version is a staged rebuild: the worst, most central part of the system rebuilt first and run alongside the old system, with the rest migrated once that's proven out, not revealed as broken halfway through a big-bang rewrite.

A short checklist

• Do unrelated features reliably break when you add something new?
• Could any one person explain the whole system end to end right now?
• Is the underlying framework or language still actively maintained?
• Has the cost per feature risen while feature size has shrunk?
• Would a staged rebuild of the worst part be safer than patching it again?

If two or more of these are true, a second opinion is worth having before the next patch. Our software development service starts any rebuild with a code review of what's actually there, not an assumption that a rewrite is the answer. Get in touch to talk it through.