Is Your Custom Software Driving Your Business, or Are You Driving It? 5 Signs It's Time for a System Refactor

A logistics company in Johannesburg had a custom system built five years ago. It did exactly what they needed at the time: track jobs, assign drivers, generate invoices.

Today, it does the same things. The business doesn't.

They've added 12 drivers, entered two new provinces, started using Xero for accounting, and launched a client portal. None of that connects to the original system. So every afternoon, a staff member sits down and manually copies job completions into Xero. Another exports a CSV, cleans it in Excel, and re-imports it into the client portal. Two people spend a combined three hours per day doing work that no computer should require a human to do.

When we spoke to the operations director, her description was concise: "The system works. We've just built a job around keeping it alive."

That is the signal. When software stops absorbing the complexity of your business and starts generating it instead, something has fundamentally changed — and it isn't the software.

Why custom software drifts

Custom software doesn't break on a specific day. It drifts.

It was built for a version of your business that no longer exists. The team has grown. The product range has expanded. You've added new tools — accounting software, a CRM, a payment gateway — and none of them know the original system exists. Third-party APIs that the system relied on have been deprecated or changed their authentication model. Developers who knew the codebase intimately have moved on, and the person maintaining it now treats it carefully, like a structural beam nobody wants to load-test.

The result is a system that technically functions but operationally constrains. It doesn't fail loudly. It fails quietly — in the hours of workaround your team treats as normal, the spreadsheets running parallel to the system, the integrations that never got built because "it's complicated."

The cost of this drift is real. It's just distributed across your team's time in increments that never get consolidated into a single line on a budget.

Sign 1: Double data entry has become part of the job

If someone on your team enters the same information into two systems — your software and your accounting package, your CRM and your invoicing tool, your job system and the spreadsheet that "the client likes" — that is not an operational quirk. That is a symptom.

Every second piece of manual data entry is a tax on your team's time. It is also a source of error. The invoice amount that doesn't match the job record. The address that got updated in one system but not the other. The customer credit limit that someone changed in Xero six weeks ago but that your quoting tool still doesn't know about.

The root cause is almost always one of two things: the integration was never built, or it was built but has since broken and nobody noticed until a discrepancy surfaced.

Neither of those is a permanent condition. Both of them are fixable. But they require someone to acknowledge that "this is just how it works" is not a satisfactory answer for a business process that runs every day.

Sign 2: Your team has built unofficial workarounds around the official system

Watch what your team actually does, not what the system is supposed to make them do.

If the job management system requires six steps to close a job but your dispatcher has a WhatsApp group where the techs actually report completions — the WhatsApp group is the real system. The official one is the audit trail.

If your sales team keeps a running spreadsheet of "active deals" because the CRM is "too slow to pull up on site" — the spreadsheet is the real CRM. The official one is the database nobody trusts.

Workarounds like these are a form of institutional adaptation. Your team is solving a problem. But they're solving it in a way that creates invisible risk: the data that lives in the WhatsApp group doesn't feed into reporting. The deals in the spreadsheet don't trigger the follow-up automation. The decision-makers are operating on information that's partially out of date, because the real workflow and the recorded workflow have quietly diverged.

This is worth paying close attention to, because teams rarely flag this directly. They've normalised the extra step. When you ask "how does this work?", they'll describe the workaround as if it's the process — because, for them, it has become the process.

Sign 3: Third-party integrations are fragile or broken

Software that was built five years ago was probably connected to third-party services using APIs that existed five years ago.

APIs change. Providers deprecate authentication methods, restructure endpoints, and retire old versions with varying degrees of notice. When that happens, the integration breaks — sometimes loudly (an error everyone sees), more often silently (the sync just stops, and nobody notices until the data discrepancy surfaces three weeks later).

The classic failure mode: a finance team member discovers at month-end that the invoicing integration with Xero hasn't been syncing since the OAuth token expired six weeks ago. Every invoice for the past six weeks has to be reconciled manually. What was a five-minute job becomes a two-day project.

Beyond token expiry, there's a harder problem: APIs that were integrated against may no longer be the right integration at all. Your business is now using a different payment gateway. You've switched from one CRM to another. You're on a new version of your accounting software that has a different data model. The original integration was built against a world that's been superseded, and nobody has had the budget or the mandate to update it.

Each of these broken or outdated integrations is a place where your systems stop talking — and a human picks up the gap.

Sign 4: Reporting requires manual extraction and assembly

If generating a business report requires someone to export several CSVs, open Excel, paste data across tabs, apply formulas, and format the result — your data is not in one place.

This is more than a convenience problem. It means your decision-makers are always operating on information that is, at minimum, as old as the last manual extraction. Monthly reporting means monthly visibility. If the extraction takes a day, reporting week is a week behind.

The compounding problem is reliability. Each manual step is a place where the wrong column gets selected, the date filter is set incorrectly, or a formula breaks because someone inserted a row in the wrong place. Over time, there are usually multiple versions of "the report" floating around with slightly different figures, and at least one leadership meeting per quarter where someone raises a number that doesn't match someone else's.

Custom software should be producing its own reporting output — dashboards, exports, summaries — from a single data source. When it isn't, the architecture of the original system probably didn't anticipate the reporting needs of a business that's grown significantly since it was built.

Sign 5: The system slows down onboarding new staff

Consider what it takes to onboard a new employee into a system that wasn't built with onboarding in mind.

There's no intuitive flow. There are screens that do things nobody does anymore, but removing them would "break something." There's institutional knowledge — held by one or two long-serving employees — about which buttons to press in which order, which fields to ignore, which workarounds to follow. The documentation either doesn't exist or was written for a version of the system that no longer matches what's on screen.

When this knowledge lives in people rather than in the system design, the business has a fragility problem that goes beyond productivity. If the person who knows how to close a job in the right sequence leaves, the next person has to be trained by memory and trial-and-error. Mistakes get made. Data gets corrupted. The system becomes more unreliable over time, not because it was built badly, but because the business has been carried forward by the same handful of people while the system stood still.

A refactored system should be self-evident to a new employee with reasonable computer literacy. If it isn't, the design has accumulated a debt that will keep compounding.

Refactoring is a business decision, not a technical one

The mistake most businesses make when approaching a software refactor is framing it as an IT project.

It isn't. It's an operational decision with a financial justification.

The right questions are:

• How many staff hours per week are being spent on tasks this system should handle automatically?
• What errors or discrepancies are we cleaning up manually each month — and what do they cost?
• What business decisions are being made on incomplete or stale data because reporting is hard?
• What opportunities are we not pursuing because the system can't accommodate them without a major workaround?

When you put those numbers together, a refactor that looks expensive on paper often pays for itself within a year. The operational friction isn't invisible — it's just distributed across the business in a way that doesn't appear as a line item.

A refactor doesn't mean rewriting everything from scratch. It often means:

• Replacing broken integrations with current, maintained API connections
• Building a proper data layer that gives reporting direct access to live data
• Removing accumulated technical debt in the parts of the codebase that are most frequently changed
• Adding a modern front-end layer over a back-end that still has good logic

The goal is a system that your team works with, rather than one they work around.

What a refactored system actually looks like

Take the logistics company from the start of this article. The back-end logic for job dispatch and driver management was sound — it had been in production for five years and the edge cases were well-handled. What it lacked was the connective tissue to the rest of the business.

The refactor involved:

• A proper Xero API integration using current OAuth 2.0, with a sync that runs automatically and alerts finance when it fails
• A client portal that reads directly from the job database rather than from a CSV export
• A reporting dashboard that any manager can open and see live job completion rates, revenue, and outstanding invoices without touching a spreadsheet
• A modern front-end built over the existing back-end, with role-based access that made onboarding a new dispatcher a 30-minute task rather than a two-day shadow

Total rebuild cost: less than the annual salary of the staff member who had been managing the manual processes. Payback period: under four months.

None of this required the original system to be discarded. It required someone to acknowledge that the system, as it stood, was costing the business more than a targeted investment in fixing it would.

The questions to ask before you start

If you're recognising your business in any of the five signs above, three questions are worth working through before committing to a refactor:

1. What does the system do well that we must not break? There is almost always core logic — pricing rules, job sequencing, access controls — that has been refined over years and must be preserved exactly. Any refactor brief needs to document this explicitly before a developer touches anything.

2. Where does the most friction come from, measured in hours? Start with the highest-cost pain points. A targeted fix to double data entry between two systems is deliverable in days. It doesn't require a full rebuild. Prioritise by time cost, not by how annoying the problem feels.

3. Who needs to be involved in defining what the new system should do? The people closest to the workflow — the dispatchers, the finance team, the account managers — know the real requirements better than anyone. If the previous system was built to a specification written by a manager who doesn't use it daily, the refactor should correct that.

---

If your custom software is generating more work than it's eliminating, the problem isn't that custom software was the wrong choice. It's that the software you built five years ago was the right fit for a business that's no longer the same size or shape.

We build and refactor custom software for South African businesses. If you want a frank assessment of where your system is and what it would take to modernise it, reach out — the conversation is free.