The Hidden Cost of Customising Someone Else's Platform

Heavy customisation of a commercial platform is frequently sold as a middle path between building and buying — you get a proven product plus a fit tailored to your needs. In practice it is often the worst of both worlds, not the best. This is a companion piece to our build vs buy framework.

Why customisation compounds rather than settles

A platform's core codebase is controlled by its vendor, not you. Every customisation you build on top of it has to survive the vendor's next update, which you do not control the timing or content of. This is structurally different from customising your own codebase, where you decide what changes and when.

You pay licence fees like a buyer. The ongoing subscription or licence cost does not disappear because you have customised the product — you are still paying for the base platform, plus now maintaining a layer built on top of it.

You pay maintenance costs like a builder. The customisation layer needs its own testing, its own bug fixes, and its own updates whenever the underlying platform changes — this is genuine software maintenance work, requiring genuine software engineering skill, on code that only exists because the base product didn't do what you needed.

You get neither the product roadmap nor control of your own system. You cannot influence what the vendor prioritises in their roadmap the way you would control your own product's priorities, and you cannot freely change your own customisation layer without checking it against a base platform that changes on the vendor's schedule, not yours.

Why this trap is easy to fall into

The decision to add "just one customisation" rarely feels like the decision to take on a maintained codebase — it feels like configuration, an extension of using the product rather than building something new. Each individual customisation seems small and reasonable. The accumulated total, years later, is a substantial custom system, built inside someone else's platform, that nobody explicitly decided to build.

What breaks specifically

Platform updates silently conflict with customisations. A vendor's routine update can break a customisation built years earlier by someone no longer at the organisation, and the failure often surfaces at the worst possible moment — during the update itself, in production.

Upgrade paths become progressively harder to take. The more customisation accumulated, the more expensive and risky each subsequent platform upgrade becomes, which creates pressure to defer upgrades — accumulating exactly the kind of technical debt covered in our dedicated piece, on a foundation you don't even control.

Institutional knowledge of the customisation layer decays like any other codebase. The person who built a critical customisation five years ago may be gone, and unlike the vendor's core product, there is no vendor support line to call about your own bespoke additions.

The decision point that should trigger a rethink

If a proposed customisation would take substantial development effort — comparable to what a modest custom feature would cost to build independently — that is the signal to stop and reconsider, not to proceed on the assumption that customisation is inherently the cheaper or lower-risk path. At that scale, you are not customising a product anymore. You are building custom software, on someone else's platform, with someone else's constraints, and you should compare it honestly against the alternative of building it on infrastructure you actually control.

Questions worth asking before a significant customisation

What does this customisation cost to maintain through the platform's next three major updates, not just to build once?

If the vendor changes their roadmap or is acquired, what happens to this customisation?

Would this be simpler, more maintainable, or cheaper as a custom-built feature outside the platform, integrated with it rather than built inside it?

Who, specifically, will maintain this customisation over its lifetime, and what happens when they leave?

What we do

When a client proposes a significant customisation to an existing platform, we run the comparison against building the capability independently before recommending either path — because the "just customise it" instinct is frequently wrong at scale, even when it feels like the path of least resistance. If you are weighing a significant customisation against building something custom, that is a conversation we are glad to have.

Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions.