Custom software or off-the-shelf? How to decide without regretting it

Sooner or later, every company reaches this crossroads: you need software to do something better, faster or in a more organised way. And two paths immediately appear. Either you buy a ready-made solution that already exists on the market, or you have something built to measure for your business.

It looks like a technical decision. It isn't. It's a business decision that will shape your company for years. And it's one of the decisions I most often see Portuguese SMEs trip over, in both directions. Some have a system built from scratch when a 30-euro-a-month subscription would have done the job. And others spend five years contorting their business to fit inside a tool that was never designed for them.

Let's lay this out plainly, no jargon, nothing being force-sold.

First, what each one is

Off-the-shelf software (often called SaaS, software as a service) is a ready-made product that many companies use at the same time. You pay a subscription, usually monthly or yearly, and you get access. Think of a CRM like HubSpot, an invoicing tool, project management software like Asana, an e-commerce platform like Shopify. Someone has already built it, maintains it and sells it to thousands of customers. You're one of them.

Custom software is built specifically for your company. It solves your problem, your way, with your rules. There's no subscription shared with anyone else, because nobody else has this software. It's yours. You pay to build it and you pay to maintain and evolve it.

Put like that, it seems obvious that custom is "better". It isn't. They're different tools for different situations. A hammer isn't better than a screwdriver. It depends on the nail.

When off-the-shelf wins

In most cases, for most tasks, buying ready-made is the right call. And I say that as someone who makes a living building custom software.

When your process is standard. Invoicing, managing contacts, sending newsletters, scheduling meetings, doing accounts. There's nothing special about how your business does these. You do them the same way as everyone else, and that's fine. There's no advantage in reinventing invoicing. Excellent tools already exist, tested by millions of companies, that do this better than anything you'd have built.

When you want to start now. An off-the-shelf solution is working tomorrow morning. You create an account, configure it, and you're up and running. Building custom takes weeks or months. If you need to solve the problem now, the maths is simple.

When the upfront cost matters. Paying 50 euros a month is much easier to swallow than an upfront investment in a development project. For many tasks, the subscription is the financially sensible choice, especially while you're validating whether you even need the thing.

When you don't want to deal with maintenance. The vendor handles everything. Servers, security, updates, bug fixes, new features. You just use it. This has enormous value and plenty of people forget to count it. Keeping software running is serious work.

When custom wins

There are situations where insisting on an off-the-shelf tool costs you more, in money and in headaches, than building what you need.

When your process is your differentiator. If the way you do something is precisely what makes you better than your competitors, squeezing that into a generic tool is killing the goose that lays the golden eggs. Picture a logistics company with its own route-optimisation method that nobody else has. Forcing that into standard software makes it work like everyone else, and the advantage disappears.

When you need deep integrations. When your systems have to talk to each other smoothly, the ERP communicating with the website, with stock, with invoicing, with customer support, without anyone copying data by hand between windows, often only custom connects the dots the way you need.

When the tool forces you to change how you work. This is the most treacherous one. You adopt an off-the-shelf solution and, little by little, instead of the tool serving your business, it's your business that contorts to serve the tool. You change processes that worked well just because "the software won't let you do it any other way". When you start shaping the company to the software instead of the other way round, that's an alarm bell.

When licensing costs balloon with scale. Many tools charge per user, per transaction or by volume. What was cheap with five people becomes heavy with fifty. There's a point where the monthly subscription accumulated over the years overtakes, comfortably, the cost of having built your own solution.

When you're stitching tools together with manual work. If you have three, four, five different tools and a person whose job is, basically, to copy information from one to the next, export an Excel from here to import it there, you're paying twice: the subscription for each tool and the salary of whoever bridges them by hand. Often, a custom system that pulls those together pays for itself.

The reality is hybrid (and that's perfectly fine)

Here's the part nobody tells you when they're trying to push one thing or the other: the overwhelming majority of healthy companies use both. And that's exactly how it should be.

The typical setup of a well-run SME isn't "all custom" nor "all off-the-shelf". It's using excellent standard tools for what's standard, invoicing, email, accounting, and building custom only what truly matters, usually the glue that ties everything together and the processes that set you apart.

Picture a small piece of custom software that takes what comes in through your website, organises it your way, and automatically dispatches it to the off-the-shelf tools you already use. You didn't build a new CRM, or an invoicing system, or an e-commerce platform. You bought all of that ready-made. You only had the bit built that nobody else has and that keeps your operation running without anyone copying data by hand.

This is the smart way to think about it. It isn't off-the-shelf versus custom. It's off-the-shelf and custom, each in its proper place.

The cost nobody adds up: TCO

Most people decide by looking at the entry price. "This tool costs 40 euros a month, building custom costs me a whole project, therefore the tool is cheaper." This is where it goes wrong.

What matters is the total cost of ownership over time, what's known as TCO. And there the picture changes.

A subscription is forever. You pay every month, year after year, for as long as you use it. And the price tends to go up, not down. Multiply the monthly fee by the number of users, then by five or ten years. The number you get usually surprises people.

Custom software runs the other way: a bigger upfront investment, then a much lower and more predictable cost of maintenance and evolution. It doesn't vanish, custom software needs care too, but you don't have the per-head monthly fee growing along with you.

I'm not saying custom always works out cheaper. Often it doesn't. I'm saying you have to do the maths in the right window. Comparing the price of one month's subscription with the cost of building is comparing different things. Compare five years with five years. Then you're deciding with the full picture.

Lock-in and who owns your data

There's a question almost nobody asks before adopting a tool, and it should be one of the first: if one day I want to leave, can I?

Vendor dependency, the so-called vendor lock-in, is real and expensive. Some off-the-shelf tools are designed so that getting in is easy and getting out is a nightmare. Your data sits in a format only they read, there's no simple way to export it, and when you decide to move you realise you're stuck. The price goes up, the service gets worse, and switching would cost so much that you put up with it.

Always ask, before you go in: who owns the data? Can I export it in an open, usable format? What happens if the company shuts down, gets bought or triples its price? If the answer makes you uncomfortable, you already know the risk you're taking on.

With custom software this problem doesn't exist in the same way, the data and the system are yours. But careful, custom has its own kind of dependency: you become dependent on whoever built and maintains it. That's why well-documented code, free of lock-ins, and full ownership of the code matter so much. A good partner hands you something another person can pick up and carry on. A bad partner hands you a black box only they understand. That's lock-in too, just wearing a different face.

A simple framework for deciding

Without overcomplicating it. Before you choose, run the problem through these questions:

1. Does this set me apart from competitors? If not, lean towards buying ready-made. If yes, and it's genuinely central to your business, custom starts to make sense.

2. Does something already exist that does 80% of what I need? If a tool solves most of it and the missing 20% isn't critical, buy it and adapt. Don't build from scratch to gain a few tweaks.

3. Does the tool force me to change processes that work? If the only way to use the product is to change how you work on things that already work well, that's a bad sign.

4. What does this cost me five years from now? Do the TCO maths, with the growth you expect. Compare equal windows.

5. Am I stitching tools together by hand? If the problem is people moving data from one place to another, maybe you don't need another tool, but rather custom glue between the ones you already have.

6. If I want to leave, can I take my data? Check this before you go in, not after.

There's no universal right answer. There's the right answer for your case. And it's almost always a mix: buy nearly everything, build the little that's genuinely worth it.

Build only what's worth building

If there's one idea to take away from this article, it's this: the goal isn't to build as much custom software as possible. It's exactly the opposite. It's to build the minimum, only what gives you a real edge, and buy everything else ready-made.

The worst decision is building from scratch something that already exists, better, on the market. The second worst is spending years torturing your business inside a tool that wasn't made for you, just because it was cheaper in the first month. The trick is knowing how to tell the two cases apart, and that means looking at the business before looking at the technology.

This is what we do with the SMEs we work with. We don't show up selling custom development as if it were the answer to everything. We start by understanding what you actually need, and often the honest recommendation is "for this, buy this tool, it's not worth building". Custom is reserved for where it makes the difference: the integration that ties everything together, the process that's yours and nobody else's, the glue that takes the manual work off your plate.