Some expressions seem to come with an implicit promise. “Custom-made” is one of them.
In almost any context, from a tailored suit to a professional service, we tend to assume that something designed specifically for us will be better: more carefully considered, more comprehensive and better suited to our needs.
And it is only natural to apply that same perception to technology. However, when it comes to software, the most customised option is not always the one that works best or delivers the greatest value in the long term.
I see this frequently when we talk to an organisation looking for an LMS. The conversation usually starts with questions about features, users or specific requirements. But sooner or later, a request comes up that seems almost inevitable:
“Can this be customised?”
Sometimes the question goes a little further.
“Can we have a specific feature?”
“Can we change this process?”
“Can we make it work exactly this way?”
These questions are completely understandable. We all want technology to adapt to the way we work. But it is important to distinguish between customising a platform and developing a different version for every client.
A SaaS solution can be flexible and configurable, adapting to different processes, permissions, communications, integrations or visual identities while retaining a shared core. Modifying that core with bespoke developments that then need to be maintained and evolved independently is a very different matter.
Interestingly, the request to develop something specific often arises before an organisation has even started using the platform. As though a standard solution were, by definition, insufficient. As though a custom platform were necessarily superior. And I think it is worth taking a moment to consider whether that is really the case.
Custom-made has a very good reputation
This perception also influences how we approach a new technology project. Before we even start using a platform, it is easy to form a very precise picture of everything we would like it to do and exactly how we would like it to work.
We want a particular process to work in a certain way, a specific button to appear, users to follow an exact journey, the interface to have certain features, or a particular function to behave differently because that is how our organisation works. And technically, much of this can often be done.
The problem is that custom development does not end when the software goes live. That is when a less visible phase begins: maintenance and ongoing development.
Every update means reviewing the customisations that have been made to ensure they continue to work correctly as the technology changes. This requires time, resources and specialist expertise. The greater the amount of custom code, the more demanding it becomes to manage in the long term, and what initially seemed like an advantage can end up creating complexity that had not been anticipated.
Test before you build
Before launching a new project, it is common for an organisation to build a picture of its perfect LMS. We imagine how processes should work, what journeys users will follow, which reports we will need or which features will be essential.
However, that ideal platform is usually defined before we have seen how it will actually be used, what difficulties the team will encounter, what learners will ask for or what data will genuinely be useful for managing and improving training. At this stage, we are not designing based on experience, but on assumptions which may be perfectly reasonable, yet remain assumptions nonetheless.
That is why, before turning all these ideas into custom development, it may make more sense to start with an existing solution, configure it for a specific project and test it through a pilot.
That initial experience allows us to understand how the platform will actually be used, see how users respond, establish priorities and distinguish between what seemed necessary and what genuinely adds value.
We may then confirm that we need to move towards custom development, but we will do so with far greater insight. Or we may discover that a much simpler solution already does everything that really matters.
Standard doesn’t have to mean basic
This is another perception we should reconsider. When we talk about a SaaS solution that is easy to subscribe to, requires no installation and comes with an affordable monthly fee, some people assume it must be a basic tool: limited, small-scale or less powerful than one developed specifically for them.
However, that is not necessarily the case. The fact that a solution requires no installation or is affordably priced does not necessarily mean that it is a basic tool.
In fact, the opposite is often true.
Think about some of the digital services we use every day. Microsoft 365, Canva and many other tools operate on subscription models. We do not purchase a different development for each company, nor do we use a version created specifically for us. We use a shared product that is constantly evolving and, in all likelihood, that is one of its greatest strengths.
The SaaS model is built on precisely this philosophy. There is a shared product core for all clients. Whenever a feature is improved, an issue is fixed, security is strengthened or a process is optimised, those improvements become available to all users.
That changes things considerably, because the software no longer evolves solely around the needs of a single organisation; instead, it benefits from the accumulated experience of many organisations.
The value of collective knowledge
There is another advantage to this model that can sometimes go unnoticed. A SaaS platform accumulates knowledge: collective knowledge that ultimately becomes part of the product.
When the same platform is used every day by thousands of organisations, administrators and trainers, as well as hundreds of thousands of learners, the software is constantly being put to the test in real-world situations.
In other words, it is used in different ways, different needs emerge and patterns of behaviour are identified that the development team may never have anticipated. Based on that experience, issues are fixed, processes are optimised and new opportunities for improvement emerge.
Each client uses the SaaS platform for their own project and, at the same time, indirectly contributes to the product’s evolution.
And I think that is an important distinction.
With a solution developed exclusively for one organisation, its evolution depends on that organisation’s needs, budget and ability to continue investing. With a SaaS solution, an improvement that addresses a common problem can be incorporated into the product and made available to all clients.
When does a custom solution make sense?
There is no single answer. Some organisations have highly specific processes, genuinely unique requirements or business models for which a standard solution simply is not enough.
If we know exactly what we need, have tested it in a real-world environment, understand why no existing solution can meet that need and are prepared to bear the cost of developing, maintaining and evolving it, then custom software may well make sense.
But before reaching that conclusion, perhaps we should ask ourselves whether that requirement is genuinely essential. Sometimes, we ask technology to replicate our existing processes exactly without questioning whether those processes are still the best way to work.
Perhaps we should turn that reasoning around.
First, we need to understand what we want to achieve. Then we should see whether there is an e-learning platform that already meets that need and, wherever possible, test it through a pilot project. Only when experience confirms that no available solution can meet that requirement does it make sense to consider building something different.
It may seem like a small distinction, but it completely changes the way we approach a technology project.
Start with the need, not the customisation
After years of working in this sector, I have become increasingly convinced that, when making technology decisions, we tend to think about what we might need one day rather than focusing on what we actually need today.
Sometimes we will discover that a standard solution is enough. That we do not need to create an entirely new process. That a particular button, a specific modification or a feature developed exclusively for us will not deliver as much value as we thought.
Other times, that will not be the case. And we will need to find or build a different solution.
Technology should help us move forward, not become a constant source of concern. Ultimately, an LMS platform does not create value through the amount of custom code it contains, but through its ability to help people learn, make life easier for those managing training and evolve alongside the organisation’s needs.
At evolMind, we believe in the SaaS model for precisely this reason. Not because we think custom solutions are always the wrong choice, but because we believe that, for many organisations, technology should not become a project in its own right.
The best solution is not the one that allows us to change everything. It is the one that gets the important things right and allows us to focus on our real goal: improving training.
