5 Reasons NOT to Customise Your SaaS Software

I'm a big believer in buying off-the-shelf products like Salesforce and Dynamics 365 to do the stuff that every business does, like finance, sales, pipeline management, and if you're selling widgets and standard stuff, also for internal order management. Make sure they do the fundamental 10 things you need them to do, buy them, implement them, and get your sales teams, your customer onboarding teams, and your finance teams to use them exactly as they were sold to you out of the box.

However, DO NOT customise vendor technologies like Salesforce and Dynamics 365, and don't use these products to build new solutions in your organisation. Don't fall into the trap of extensively customising the base product or, even worse, building new custom solutions for some other random business process, like customer-facing applications or digital self-service or anything else. The vendors of these products have big marketing and sales budgets, and they don't just want you to buy their product for the 10 people in finance or the 20 people in the sales team.

No, they want hundreds of people in your organisation using custom solutions you've built using their product as a base technology for software development. They can sell you more licences of the base product, even though you're not using the base product in finance or sales. They use fear and silky promises to win you over.

From a fear perspective, they'll use things like, "Oh gee, you don't want to build a legacy for yourself or create technical debt," despite the fact that you'll be building a legacy and creating technical debt inside their solution. From a silky promise point of view, they'll say, "Oh, you know, our tool is much lower cost, you can configure it, it's a low-code platform, you don't need such expensive resources," despite the fact that it's not low cost, it is software development, not configuration, and you have created a technical debt and legacy that is going to cost you more to change.

So don't be led by the nose by your vendors; they've got a conflict of interest, and you should be aware of that. Instead, have a chat with anyone like me or anyone in the industry who has experience customising these products or building new solutions using their technologies, and they'll tell you the same thing. They'll say run away, run fast and run far, because if you start customising, you'll never be able to stop.

You'll throw good money after bad because once you start, it's career suicide to go back. And here's precisely how that's going to hurt. I'm summarising at least 100, probably 200 first-hand accounts over the last couple of decades from practitioners in the field, people who have gone deep on this idea time and time again.

1: When you customise the base product, you destroy your upgrade path. You'll still be on the same version of whatever product you bought last decade, or you will have spent a fortune manually upgrading it. Most likely, when you upgrade it manually, you'll be rebuilding all the customisations again in a sort of groundhog day cycle, and the reason for that is the person who made that mistake last time left nine years ago. But now, you're making the decisions and you've got the vendor sales team in your ear selling you all the same ideas.

2: Most of the new solutions you've built on vendor technologies will have failed. The reason for that is that users will have not adopted it. The reason they haven't adopted it is because the user experience is so poor that people would rather use a spreadsheet and do things semi-manually. These tools are limited in their ability to support an experience that fits the user.

3: For the few that succeed, you still have custom stuff. It's still custom stuff, but it's the most expensive custom stuff you've ever built and operated. The total cost of ownership is horrendous. First, the resources that you've had to hire are less ubiquitous. You're talking about 1% of the available development market. They're more expensive and harder to find. (Their rarity, by the way, is not a function of extreme skill. Their rarity is a function of how unpleasant this kind of software development work is.) And, they tend to work slower than other developers.

Second, instead of thinking of a solution and building it, you spend your time trying to work around the product because this product is not a professional software engineering environment. You end up modifying your concept around the product instead of building the right product for your organisation and your users. It takes longer to try and bend your solution around the product. It costs more money. You've got more people sitting around doing stuff for longer, so your budget goes up.

Third, the development tools are much less productive. They just don't support all of the best practices in DevOps. The most important part of the DevOps lifecycle, as an example, is the part where you're building and testing things on your local machine, and with vendor tools, there's no way of doing that. Vendor tooling slows the entire process down.

4: The operating costs of any product are higher because you've got licensing. Ubiquitous, free software engineering tools that the other 99% of the market are using don't have those licensing costs. The hosting costs, if you choose the right technologies, are way lower. Big platform vendors often say misleading things about their competition, and they'll try to scare you into thinking that free or open-source software engineering tools and frameworks are high-maintenance or insecure. Because these tools have a low or zero cost, it's easy to believe these misleading ideas. Don't. Standard software development tooling exists within a broader ecosystem of standards and best practices that can very effectively address risk, change, maintenance, and security.

5: You've got a bigger technical debt, but it's harder to maintain. Mostly for the same reasons that I've just mentioned in terms of being more expensive to build a solution, but also because it's a closed ecosystem, so there are almost no standards or best practices. Five developers will build the same thing five different ways in contrast to professional software engineers who will stick to standard conventions, patterns, structures that are easily recognisable by others. That means that when future developers pick up the code you've built on top of a product, it's harder to understand, and what you'll find is people pick it up, realise it's quicker to rewrite than it is to understand, and end up making changes to your code way in excess of what is actually needed in order to maintain it, and they'll blame the previous team for their lack of skills, which is also a myth.

Don't take my word for this stuff. Just find someone who's done it before, buy them a bottle of wine (and a box of tissues), settle in for a few hours, and just listen. You'll hear all of these things.

Extending vendor software, building your own solutions, building your own integrations is a necessary part of any organisation of 50 people, but extensively customising vendor platforms for this is something you'll regret. I'll write something on the right way to do this shortly. It's way easier than you think.

You just need to put earplugs in when your vendor sales team comes to visit and follow a couple of simple rules, and you'll be building better software, faster, that costs less to maintain and has a lower technical debt. You'll be creating more impact with less cost.

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