Off the shelf software versus custom-built applications

TLDR: Go with an off the shelf application if you can live with it without needing to modify it with custom code. If you know you’re going to have to make significant code changes, bite the bullet and create a custom application.

Introduction

Lets kick things off with some definitions:

• Off-the-shelf software: Software that’s pre-built, ready to use, and designed for broad use cases across industries. Examples of this might include Salesforce, Peoplesoft, SAP, or even Excel.

• Custom applications: Tailor-made programs built specifically for your organization. They’re made to fit your specific workflows, goals, and aim to meet your particular objectives.

OTS Software

With off-the-shelf software the main advantages that you’re getting are faster deployment times and lower upfront costs. The software comes in as a pre-built package and you just need to drop it in and go. Another advantage is that you get access to a wealth of pre-existing information online as well as pre-trained and experienced consultants who are well versed in that ecosystem. This makes it easy to customize the application to meet your needs.

The main trade-off is that while usually available, customization is limited. You’ll need to bend to fit pre-existing workflows, not the other way around. There are usually far too many bells and whistles, leading to feature overload and you suffer from vendor lock-in. There might also be possible compliance gaps if the software is not specifically targeted at your business niche.

Custom Applications

On the other hand, with a custom built application, you get something which is tailored to fit you and your organization’s specific needs. So no need to shake up the entire company and re-train a lot of folks. You can also use it to create a competitive advantage or a moat around your business as you can add unique capabilities that your competitors can’t buy off a shelf.

On the flip side, this approach comes with a much higher initial cost and it can take a lot more time to get up and running. There’s also an ongoing maintenance overhead since you own the bugs, the servers, and all the associated headaches which come with running the application yourself.

So what should you go for?

If you can live within the constraints of using something that’s off the shelf; it is a no-brainer — just do it. It’ll be a lot faster, cheaper, and come with much lower risk. This is especially true if you are a smaller organization and you can mould yourself to fit around the constraints of the application. Avoid customization as much as possible. When I say customization, I mean adding custom code on top of the application. If the application supports native workflows or other ways to setup the application to fit your needs, that should be fine.

However, If you are too large to be quite so flexible and you need to make the software fit you rather than the other way around, then just bite the bullet and go down the custom route. Avoid the mirage of those potentially lower initial costs. The overall cost will end up being much higher in the medium to long term.

Why not go with something in the middle?

It’s a trap. Instead of getting the best of both worlds, you end up with the worst of both of them.

For one, you’re locked into the vendor’s upgrade cycle. This is especially true if you’re on their cloud environment if they have that option. Now you can’t control how or when new features come in and old ones get deprecated. As they go down their development roadmap, chances are your custom code is going to break unless you update it to match.

Secondly, you now have to hire product specialists who are much more expensive than general programmers, which is going to bump up your costs. Hiring generalists and training them up might also not work out since many coders may not want to work within the guts of a specific off the shelf app. You’re going to have to look for people who are comfortable going down that career specialization path, which isn’t for everyone.

Furthermore, your customizations are limited by the base software and the design decisions taken by the vendor. You’ll have to live with the decisions they’ve taken for their tech stack, overall architecture, scaling strategies and so on. Those decisions were not taken with your specific needs in mind, so the chances of them matching them are slim.

Related to the previous point, you can’t refactor the core application code to fix issues or make it work better for you. I mean you can in most cases, it’s just that it’s going to completely break the upgrade path for you. So you’re stuck with whatever bugs and inefficiencies that are baked in, even when you can fix them yourself.

Lessons from the trenches

This isn’t something theoretical. I’m working with two such projects right now and we’ve got:

• High-priced consultants who are sucking us dry.
• An internal team we’re trying to train up, but people leave soon after they get some experience in, because now they’re the high priced specialist and they can get a much higher salary elsewhere.
• Strange intermittent performance issues we can’t trace because we’re running on a shared cloud environment and we don’t have complete admin access to the entire cloud setup.
• No easy access to all the logs in the way we need because of certain imposed space limitations.

And even after spending some five years building all this up, we’re still adding features to these applications.

The Bottom Line

We could’ve built something better from the ground up in the same amount of time we’ve spent so far and probably for less money. That custom solution would be completely under our control and we would be able to mould it to our needs without having to spend half our time fighting the base system.

So the key takeaway here is, go with an off the shelf application if you can live with it without needing to modify it with custom code. And if you must customize it — do it around the platform, not on top of it. Use their APIs, REST endpoints, file load points, even direct DB access — whatever you can get away with. Build small ETLs to push and pull data. Use the built-in configuration tools — like workflows or business rules — not custom code.

Stay loosely coupled with the application. That way, your upgrade path stays cleaner and you’ll largely avoid breaking your customizations.