(1 of 3) Cheaper: Accelerating Customisations Off-Platform

This is part 1 of a 3-part series:

1. Why it’s cheaper to have your customisations “off platform”

2. Why it’s faster to have your customisations “off platform”

3. Why it’s better to have your customisations “off platform”

Cost of Implementation & Operation:
On-Platform vs. Off-Platform

Let me start by saying that I’m a massive fan of products like Sitecore, Salesforce, and Microsoft Dynamics 365—when they do almost everything we need “out of the box.” And what I mean by “out of the box” is that we can turn it on and start using it with perhaps a bit of training and a week or so of configuration (as opposed to coding) to tweak our workflows. I’m not talking about a 6-month project to “configure” entirely new workflows from scratch, effectively turning the SaaS product into a low-code platform or, worse, a coding tool.

Sitecore, like WordPress and Adobe, offers “content management systems” (CMSs). These were designed to run websites and intranets, not as development tools for building secure digital solutions.

Salesforce is, at its core, a customer relationship management (CRM) system. It was designed to make sales and marketing teams more efficient and transparent, not to serve as a platform for building new digital solutions in other parts of the business.

The same applies to Dynamics 365, which started as a CRM like Salesforce and later incorporated a separate accounting product through acquisition. Again, neither was created to build entirely new modules for other areas of the business.

And yet, it’s become standard practice to build whole new modules and features on top of the SaaS software we’ve implemented. This is called "on-platform build." While this approach benefits the vendor by driving wider use (and therefore increasing licensing costs), it's the worst place to build and operate the unique technology components needed within the organisation.

To understand why on-platform builds are such a poor choice, let’s look at it purely from a cost perspective. The next two articles will address quality and speed.

If you ask any group of businesspeople whether it’s cheaper to build new functionality on or off their shiny Sitecore, Salesforce, or Dynamics system, almost everyone will say “on-platform.” This is what we’ve been conditioned to believe by every software vendor since the 70s. And, in the 70s, it was true. But the economics have flipped from the last millennium to this one.

Today, we have access to license-free, cheap, and ubiquitous technologies upon which we can build new modules. These options didn’t exist in the 60s, 70s, or 80s. Additionally, if we are careful about the SaaS software we buy, we now have better (and cheaper) connection points for our customisations to use within the SaaS software to cooperate effectively. These are called APIs, and they should be a core requirement when selecting a SaaS product.

Why Is Building Around SaaS Software Cheaper?

Firstly, the resources needed to build customisations are significantly cheaper when using free and widely available technologies compared to SaaS specialists. SaaS specialists require numerous certifications and, therefore, command higher daily rates and salaries. This cost is compounded because, in most cases, you need multiple specialists for the same SaaS software to make any customisations useful. In contrast, with free and ubiquitous technologies, you can often find one person who can get the job done. With fewer proprietary specialists due to high entry barriers, the result is a low supply and higher costs.

From my experience, the human cost of building customisations on-platform is 2 to 3 times higher than building equivalent customisations off-platform.

Secondly, the cost of operating the software is much lower if we use more open, licence-free products. This lower cost partly comes from reduced human resource expenses, following the same logic as during the build phase. But the bigger impact comes from the licensing costs incurred when building on-platform.

On-platform customisations typically result in a need to extend the software to more users within the organisation. For example, where the initial team may have been using 20 licences, on-platform customisations often lead to wider adoption, requiring 100 people to use the solution. This drives up licensing costs significantly, and these costs recur year after year.

For some reason I haven’t been able to work out, these costs are rarely considered when choosing the best technology for customisations. It seems we’ve been conditioned by our vendors not to look too closely—we’ve been taught, and therefore assume, that it’s better to build on-platform.

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.