(2 of 3) Faster: Accelerating Customisations Off-Platform

This is part 2 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”

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

As discussed in my last article, it's standard practice to build customisations on top of the SaaS software we've implemented. This approach is known as "on-platform customisation". While beneficial for vendors—driving higher software usage (and licensing costs)—it's often the worst place to build and operate the unique technology our organisations need.

When considering implementation speed, it might seem logical that building ("configuring") new modules on platforms like Sitecore, Salesforce or Dynamics would be quicker than starting from scratch with open-source tools, right? Actually, no. For decades, we've been led to believe this, but the world has changed, upending the economic and technical assumptions that held true in the 60s and 70s.

Building customisations by configuring existing software is fundamentally different from starting fresh with powerful open-source tools. With a pre-existing SaaS product, there's a much longer lead-in time for two key reasons:

1. Specialised Resource Requirements
   First, we need resources who understand the software and know how to leverage its modules for customisation. Sourcing and scheduling such experts can take weeks or months, while finding open-market resources skilled in open-source tech is simpler and quicker.

2. Solution Complexity and Constraints
   Second, solution design isn't straightforward. We can't just build from a user's perspective; every decision must factor in how to assemble the solution using the platform's existing tools. This drags down every conversation, making even small projects feel unnecessarily complex.

Challenges with Major SaaS Platforms

This problem isn't limited to large SaaS products. It also affects local tools like the Power Platform. For example, discussions often start with decisions about using Canvas apps, Power Pages or Model-Driven apps. Most solutions need a mix of these, which immediately adds unnecessary complexity.

The same issues arise with platforms like Sitecore or WordPress when used for building secure digital experiences instead of simple content-focused websites. We end up working around proprietary knobs and levers, inheriting a massive amount of complexity for what should be relatively simple tasks.

Development Inefficiencies: Local Build and Deployment

Another reason on-platform development is slower is the lack of best-practice support for customisations in most SaaS software. The biggest bottleneck is the local build process. Off-platform open-source tools optimise this because it impacts productivity every minute during development. The person building the solution needs to make hundreds of small changes and see them work locally before pushing to shared environments.

Local development is crucial because deploying changes to shared environments is time-consuming. For something that happens continuously, any delay in this process results in a major productivity hit. In my project rescue days, ensuring solutions could run locally on every developer's machine was a key focus for boosting productivity.

Why SaaS Platforms Fall Short

Few major SaaS providers allow local running of solutions, meaning even minor changes must be deployed to a common environment. These shared environments aren't always easy to set up and require time-consuming deployments, making even small updates a hassle.

Each of these factors alone can add significant time to a project. Combined, they create massive delays—closer to 90% additional time, not just 10%.

Real-World Impact: Timeline Differences

To put this into perspective, let's consider a small solution to automate the process of getting information from a client management system into billing. This would typically need a basic user interface for ongoing data entry or configuration. For an off-platform solution, I'd expect the following timeline:

• Initial Solution Development: A couple of days

• Parallel Testing with Manual Process: Within two weeks

• Full Project Completion: Four weeks in total

That's one month from identifying the problem to having the solution fully in place.

Contrast this with the SaaS-based approach, where I've seen many confident assurances from teams claiming to match this timeline. In practice, it never takes less than three months—and often drags out to six or nine months due to false starts and complexities. There's always a reason for the delays, but at the end of the day, it just takes longer. In practice.

Final Thoughts

Ultimately, building custom solutions off-platform is not only cheaper but significantly faster. The flexibility of open-source tools, combined with the ability to work locally and iterate quickly, makes off-platform development a superior choice for many organisations. As the landscape evolves, understanding these dynamics will be key to ensuring technology investments are not just cost-effective, but also time-efficient.

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.