The short answer
Count the workarounds. If your team maintains spreadsheets alongside the platform, re-keys data between screens, or has a documented process for working around a limitation, you are already paying for custom software. You are just paying in salaries rather than in a build.
That does not automatically mean build. It means the comparison is now worth running properly.
The signals worth counting
- A spreadsheet that the real process depends on
- The same data entered into two systems by a person
- Reports assembled by hand every month
- A written procedure for working around the software
- Upgrades deferred because they break your customisations
- New staff trained on the workarounds as if they were the process
Any one of these is normal. Three or more on the same process usually means the platform and your business have diverged.
Cost the workaround honestly
| Hidden cost | How to estimate it |
|---|---|
| Manual re-keying | People times hours times weeks |
| Errors from re-keying | How often, and what each one costs |
| Reporting assembled by hand | Days per month, at what rate |
| Deferred upgrades | Security exposure and eventual migration cost |
| Key person risk | What happens when the spreadsheet owner leaves |
| Decisions delayed | Waiting for a number that is compiled monthly |
The last two rarely appear in the comparison and are frequently the largest. A business running a critical process from one person's workbook is carrying a risk nobody has priced.
What custom actually costs
Not just the build. Hosting, monitoring, security patching, dependency upgrades, support when something breaks, and change as the business moves. A custom system is an ongoing commitment rather than a purchase.
That is the honest argument for staying on a platform: somebody else carries that. The argument for building is that you have stopped getting the benefit of it while still paying the licence.
The middle option people skip
- Keep the platform as the system of record.
- Build only the piece that does not fit, as a separate application.
- Read from and write to the platform through its API.
- Leave the platform to handle what it handles well.
- Replace more only if the boundary keeps moving.
This is usually the right answer and it is less satisfying than a rebuild. You keep the vendor's maintenance and support, and you fix the specific thing that is costing you.
Deciding
Ask what you would lose by leaving the platform entirely. If the answer is a lot, build around it. If the answer is a licence fee and a login, the comparison is genuinely open.
And be honest about appetite. A custom system needs someone to own it for years. If nobody in the business wants that job, a platform with workarounds may still be the better answer.