Custom software vs off-the-shelf: when building actually pays off

A studio that builds software has an obvious bias on this question, so we will state it up front and then argue against it where that is fair. Most of the time, the honest answer to “should we build this?” is no. The cases where the answer is yes are usually the ones that matter most, and it pays to recognize them early.

This guide is for owners and managers weighing a subscription against a system built for them: the costs people forget, the traps on both sides, and the cases where building is simply a mistake.

Start with the right comparison

The usual comparison is a monthly license fee against a one-off development quote. That comparison is wrong in both directions.

Off-the-shelf software is rarely just the license. It is also the higher tier you need for one feature, onboarding, configuration, integrations, and the hours your staff spend working around what it does not do.

Custom software is rarely just the build. It is also hosting, security updates, bug fixes, and the improvements people ask for once they actually use it. Treat maintenance as a recurring yearly cost from day one, and ask any vendor to estimate it explicitly for your case. If they cannot, that is an answer too.

Total cost of ownership over three to five years

Compare over the lifetime of the decision, not the first invoice. A simple worksheet:

Off-the-shelf

• license per seat, times seats, times months - including expected headcount growth
• the higher tier you will need once you use it seriously
• implementation, configuration, data migration and training
• integrations, and whatever keeps them running
• staff time spent on workarounds: side spreadsheets, double entry, manual exports
• the cost of leaving, should you ever want to

Custom

• discovery and specification
• design and development
• hosting and infrastructure
• yearly maintenance, security updates and support
• internal time: someone on your side has to own the product, answer questions and test
• the cost of changing vendor, should the relationship end

The pattern behind the numbers is simple. License costs scale with people; custom costs scale with features. If your team grows faster than your requirements, the subscription gets steadily more expensive. If your requirements grow faster than your team, custom work keeps adding up. Neither option is automatically cheaper, which is exactly why the worksheet is worth more than instinct.

The 80% fit trap

Almost every product demo shows an 80% fit. The remaining 20% is where the decision is actually made.

Sometimes that 20% is cosmetic: a field with a different name, a report laid out differently than you are used to. Your team will adapt within a week. Accept it and move on.

Sometimes the 20% is the way your business actually makes money: how you price, how you schedule, how you handle a particular type of order, the approval chain your customers rely on. When the tool cannot model that, people work around it - a spreadsheet next to the system, a manual step every Friday, one colleague who “just knows” how to fix the numbers. Those workarounds are invisible in the license price and very visible in payroll.

A useful test: list the five processes that distinguish you from your competitors. If the product handles all five natively, buy it. If it handles none of them, buying it means changing how you work to suit the software. Occasionally that is a good idea, because many standard tools encode sensible practice. Often it is not.

Integration is where budgets quietly go

Few businesses run on a single tool. Orders arrive from a webshop, stock lives in a warehouse system, invoices go out from accounting, and somewhere in the middle a person copies data between them.

Off-the-shelf products advertise integrations, but “integrates with” can mean anything from a robust real-time API to a CSV export once a day. Find out which one you are getting. Ask what happens when one side changes its interface, who fixes it, and how quickly.

Integration is also where custom development tends to pay for itself first. A small, well-built integration layer that connects the tools you already have can remove hours of manual work every week without replacing any of them.

Data ownership and lock-in

Before signing anything, ask three questions:

1. Can we export all of our data, in a usable format, at any time?
2. What happens to our data if we stop paying, or if the vendor is acquired or shuts down?
3. What would it cost, in time and money, to move to an alternative in three years?

Lock-in is not always bad. A stable, widely used product with a clean export is a reasonable dependency. The real risk is a niche product holding data you cannot easily extract, with pricing that can change once you depend on it.

Custom software has its own version of lock-in: dependency on the team that built it. You reduce it by insisting on owning the source code and the infrastructure accounts, on documentation, and on mainstream technology that another competent team could pick up. A vendor who resists those conditions is telling you something.

When not to build

Some needs are commodities. They are solved, regulated, or simply not where your advantage lies. Building them is almost always money poorly spent:

• email, calendars and document collaboration
• general accounting and payroll, especially where local tax rules change regularly
• video calls and team chat
• a standard online shop for a conventional product catalog
• password management, backups and similar security tooling

If you find yourself writing a specification for a custom email client, stop. Nobody has ever gained a competitive edge from their own inbox.

The same applies when the process itself is still unclear. Software makes a process faster and stricter; it does not decide what the process should be. If your team cannot yet describe how something works today, start with a standard tool and learn first.

The hybrid approach: buy the core, build the edges

The most cost-effective setups we see are rarely pure. They buy proven tools for the commodity core and build only what is specific to the business:

• standard accounting, plus a small module that turns your orders into correctly structured invoices
• an off-the-shelf CRM, plus a focused web application for the one workflow it cannot model
• an established shop platform, plus an integration that keeps stock in sync with the warehouse in real time
• a custom ERP only when the operational core itself is the differentiator, and standard systems would force you to give it up

This keeps the custom surface small, which keeps maintenance small - and if one piece is replaced later, the rest keeps working.

A checklist to decide

Answer these with the people who do the work, not only those who sign off on it:

1. Does this process set us apart from competitors, or is it the same everywhere?
2. What does the best off-the-shelf option cost over five years, at the size we expect to be?
3. How much of our real workflow does it cover - measured in a trial, not taken from the demo?
4. What does the missing part cost us today, in hours per week?
5. How many systems does it need to talk to, and how reliable are those integrations?
6. Can we export all of our data at any time, in a usable format?
7. If we build, who owns the code, the hosting and the documentation?
8. Who on our side will own the product after launch?
9. Is the process stable enough to encode in software, or still changing every month?
10. What is the smallest version that would prove the value before we commit fully?

If most answers point to “commodity, well covered, few integrations”, buy and move on. If they point to “differentiating, poorly covered, many integrations”, building - or at least building the edges - is likely to pay off.

A sober conclusion

Neither option is a philosophy. It is a cost calculation with a few strategic questions attached. Do the arithmetic over a realistic time frame, include the hidden costs on both sides, and be skeptical of anyone - us included - who arrives at an answer before asking about your processes.

If you would like a second opinion on a specific case, describe it to us. We will tell you if a subscription is the better answer. It frequently is.