When should a module be rebuilt instead of repaired?

You've patched the invoicing module three times this quarter. Every fix works for a week, then something else breaks — a report stops totaling correctly, a button starts throwing an error only on Tuesdays, a colleague changes one field and suddenly the shipping calculation is wrong. Nobody on the team wants to touch that part of the system anymore, and everyone quietly routes around it instead of fixing it properly.

That feeling — "we're afraid of this module" — is the clearest signal that repair has stopped working. This article gives you a practical way to decide, module by module, whether to keep patching or to rebuild.

Why does "just fix the bug" stop working eventually?

Every patch adds a small amount of complexity on top of the original design. In isolation, each fix is reasonable: an extra condition here, a workaround there, a new field to store an exception case. But conditions stack. A module that started as a clean 200-line script five years ago can end up as a tangle of nested if-statements, each one added to handle a specific customer, a specific promotion, or a specific edge case nobody documented.

This is technical debt in its most concrete form. It's not a vague concept — it's the actual accumulated cost of every shortcut taken to hit a deadline. Interest on that debt is paid every time someone has to read the whole script just to add one field, or every time a fix in one place breaks something in another because the logic is too intertwined to reason about safely.

At some point, the cost of understanding the existing code exceeds the cost of writing new code that does the same job cleanly. That crossover point is when rebuild becomes cheaper than repair — even though it feels like the more expensive option upfront.

What are the concrete warning signs that a module needs rebuilding?

You don't need a gut feeling — you can check for these signals directly:

1. The same area breaks repeatedly. If the discount-calculation script has needed four separate bug fixes in six months, the problem isn't the last bug — it's the design.
2. Nobody wants to touch it. When your in-house developer says "let's not touch that part, it's fragile," that's a direct admission the module is no longer maintainable.
3. Fixes take disproportionately long. A one-line business rule change that should take an hour but takes three days because of hidden dependencies is a sign the structure fights every change.
4. It only survives because of one person's memory. If understanding the module depends on a developer who built it eight years ago and has since left, you have a single point of failure, not a maintainable system.
5. New requirements don't fit the shape of the old design. A module built for single-warehouse stock control that now needs to handle three warehouses, batch tracking, and API-driven stock sync from a webshop is being asked to do something it was never structured for.
6. Workarounds have become permanent. Manual exports to Excel "just for now" that have quietly run for two years are a sign the module can no longer do its job without human patching around it.

If a module shows two or more of these signs, it's a rebuild candidate — not because it's old, but because repair no longer reduces risk.

[[IMAGE:right|old tangled code module vs clean rebuilt module, side by side]]

When is repair still the right call?

Rebuilding is not automatically the responsible choice — it's a real cost, and an unnecessary rebuild can burn budget and introduce new bugs into something that was actually working fine. Repair is usually right when:

• The bug is isolated and doesn't touch the module's core logic (a display formatting issue, a missing validation, a one-off exception).
• The module hasn't needed a fix in this same area before.
• The business requirements around it are stable — nobody is asking this part of the system to do something fundamentally new.
• The fix can be made, tested, and deployed in hours, not days.

A good rule of thumb: if you can describe the fix in one sentence and it doesn't require you to first explain three other quirks of the system to someone new, it's probably a genuine repair, not a symptom of deeper rot.

How do you decide — a practical framework

Walk through this checklist for the module in question:

• How many bug fixes has this module needed in the last 12 months? (3+ suggests structural issues)
• How long does an average small change take here, compared to similar modules elsewhere in the system?
• Does at least one other developer besides the original author understand this module well enough to modify it safely?
• Are the business requirements for this module growing (new markets, new integrations, new reporting needs) or stable?
• Is there a manual workaround propping this module up today?
• If this module failed completely tomorrow, how long would it take to restore service — hours, or weeks?

Score honestly. If most answers point to instability, dependency on tribal knowledge, or growing requirements the module wasn't designed for, plan a rebuild. If the answers point to a stable, well-understood, occasionally-buggy piece of code, keep repairing it — and put your budget toward the module that actually needs attention.

What does a real rebuild-vs-repair decision look like in practice?

Consider a FileMaker-based order management system that has grown over eight years. The core order-entry module is solid — occasional small bugs, quick fixes, everyone understands it. That module stays as-is.

The stock-allocation module, though, was built for one warehouse and has been patched five separate times to handle a second warehouse, backorders, and a webshop integration bolted on afterward through a script that polls a spreadsheet export every night. Every patch has made the logic harder to follow, and the last two changes each broke something unrelated. That module is a clear rebuild candidate.

The rebuild itself doesn't have to mean starting from zero. In a modern FileMaker environment, a rebuild can mean re-architecting the data model and business logic properly, then rebuilding the interface using something like FmBetterforms so the module also gets a cleaner, more modern user experience instead of just a technical rewrite behind the same old screens. Where the module involves repetitive judgment calls — like flagging which backorders need manual review — a targeted AI layer such as Klai can be added during the rebuild to reduce manual triage, something that would have been bolted on awkwardly onto the old structure but fits naturally into a rebuilt one.

What happens if you keep repairing past the point you should have rebuilt?

The cost doesn't stay flat — it compounds. Each additional patch makes the eventual rebuild more expensive, because there's more behavior to reverse-engineer and preserve. Meanwhile the module keeps breaking in production, which means real business impact: orders miscalculated, stock counts wrong, customers affected. Teams often underestimate this because the repair costs are small and spread out, while the rebuild cost is one visible number — but added up, the repairs frequently cost more than the rebuild would have.

This is exactly the pattern described in Loggix's broader guide on how to keep business software maintainable as it grows: maintainability isn't something you achieve once, it's something you actively manage module by module as the system and the business both keep changing.

FAQ

Can we rebuild just one module without touching the rest of the system? Yes — this is one of the real advantages of a modular architecture. If the module has clear boundaries (its own tables, its own scripts, defined inputs and outputs), it can be rebuilt in isolation and swapped in, without a full system rewrite.

How do we know the rebuild won't just accumulate the same problems again? Document the business rules the old module was actually enforcing (not just what it was originally designed for) before you rebuild, and build with clear separation between data, logic, and interface. A rebuild done without addressing why the original module decayed will decay the same way.

Is a rebuild always more expensive than a repair? Upfront, usually yes. Over a 2-3 year horizon, often no — because repair costs on an unstable module tend to recur and grow, while a well-built rebuild's maintenance cost stays flat.

Should we rebuild during a slow period or just fit it in alongside other work? Rebuilding under time pressure, squeezed between other priorities, is how the original module ended up fragile in the first place. Treat a rebuild as its own scoped project with its own timeline, not a side task.

If you're staring at a module you suspect has crossed this line, it helps to get a second, technical opinion before committing budget either way. Loggix regularly works with teams to assess exactly this — reviewing an existing FileMaker module or legacy system, mapping out whether the smarter move is a targeted repair, a phased rebuild, or a modern replacement built with tools like FmBetterforms for the interface or Klai for the intelligent parts of the workflow — so the decision is based on the actual state of the code, not on how long it's been causing headaches.