(3 of 3) Better: Accelerating Customisations Off-Platform

Quality of Solution:
On-Platform vs. Off-Platform

We've discussed why it's faster and cheaper to build new functionality around vendor software (rather than using it directly for those builds) – now let's explore why it also results in a higher-quality solution.

This discussion looks at the difference between using a vendor's proprietary tools to modify and extend their software versus relying on free and widely available technologies with cost-effective, licence-free hosting. [Reference to previous article on this topic]

To build around a vendor's product, they need to have strong APIs. These "application programming interfaces" provide easy hooks into and out of the software, making it possible to build customisations around the software instead of inside it. Make APIs the #1 Requirement for Any Software You Buy

Under this banner of benefits, perhaps the most important is avoiding "upgrade lockout".

Understanding Upgrade Lockout

To understand upgrade lockout, we need to distinguish between configuration and customisation of vendor software.

Most large software vendors offer great flexibility in how information is displayed and used to fit the specific practices of any organisation. These aspects are configured by users during the initial setup, without needing IT intervention. A simple example might be renaming labels to match internal jargon instead of using Americanisms.

When vendors sell the flexibility of their software, they are selling this type of configuration.

Customisations, on the other hand, involve technical changes (code) that create a tight dependency between the specific version of the vendor's software and the added internal customisations.

For instance, building a new secure digital experience in Sitecore or WordPress will inevitably require writing code.

Unfortunately, once a SaaS solution is initially rolled out to users, it's in the vendor's interest to encourage on-platform builds. These new builds introduce new functionality for more users, leading to increased licence fees—hence the push for on-platform builds.

One or two years down the track, the vendor might release a new major version, incorporating big changes to their internal code.

At this point, configuration changes are usually safe and don't disrupt the upgrade process.

Code customisations, however, often make automatic upgrades impossible. This is what we mean by upgrade lockout: the inability to automatically benefit from new versions because our customisations are deeply entangled with the vendor's code.

This leaves us with two options: accept that we're stuck and never upgrade, or pay hundreds of thousands (often millions) in consultant fees to reapply the customisations to the new version. Ironically, these are often built the same way, leading to another dead end when the next version is released. This scenario still happens every day.

When customisations are built outside the system, using APIs, the upgrade path is protected—similar to configuration changes. Because our customisations aren't tightly coupled to the vendor's code, they remain stable regardless of changes to the underlying system. This is one of the core principles behind offering APIs: they stay stable even if the internal workings change.

For some reason, upgrade lockout is both very common and yet rarely considered when tech teams decide where to build their new modules. The best guess is that the people deciding where these customisations are built aren't the ones responsible for upgrading the vendor's software down the track, so they go along with what the vendor sells them.

Vendor Lock-In

The second major reason on-platform builds are a bad idea is that a company's intellectual property (customisations) becomes tied to the vendor's proprietary technology, even though the vendor isn't supporting it—because it's the company's work, not the vendor's.

In the future, if a company wants to move off the vendor's software, all their customisations are still completely dependent on that software.

This is called vendor lock-in because the company must keep paying for licences of the old vendor software even if they've moved to new software. So they'd be paying for two SaaS products, despite using only one.

Since this setup doesn't make financial sense, companies often stick with the old software, even if it no longer meets their needs. They are locked into a commercial relationship with the vendor because of technical reliance on their software, even though they're no longer using the core product.

User-Centric Design

The third benefit of building customisations off-platform is that we can design them in a user-centric way, rather than being constrained by the limitations of the vendor's software.

This freedom leads to a better user experience—optimised for fewer clicks and greater convenience, without being restricted by the platform's built-in functionality.

There's also a second dimension to this user experience benefit: we can create seamless experiences across multiple vendor solutions when using independent software. By definition, we can't build a unified experience across three platforms if we're using just one of them as the build tool. This results in missed digital opportunities and often forces staff to rely on swivel chair integration—where people switch between systems and re-enter the same data multiple times. The Cost of Swivel-Chair Integration

Solutions that deliver a unified user experience across systems are the ones that provide the biggest returns in terms of efficiency and morale—and these aren't possible when customisations are built on platform.

Longevity

The final benefit of using open-source, widely adopted tools for building customisations is longevity.

Before Salesforce, the market leader was Siebel. Good luck finding a Siebel developer today. They exist, but they're generally paid thousands of dollars a day to jetset around the world and fix customisations from the 90s that are now falling apart.

Open-source technologies have a longer shelf life because they're used by far more organisations than any single vendor's software. Back in 1997, Java was the go-to technology for "off-platform" customisations. There are still millions of Java developers out there, even though it's no longer the trendiest language.

In a nutshell, building customisations around vendor software, not within it, is smarter. It's not just faster and cheaper—it's better. We avoid upgrade nightmares, sidestep vendor lock-in, create user-friendly experiences, and ensure our work stands the test of time. By keeping our custom code separate and using widely-adopted tech, we're enabling sustainability over the long term. Remember this the next time a vendor pushes their proprietary tools—your future self (and budget) will thank you.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.