Custom Software vs Off-the-Shelf: How to Decide, and What Custom Really Costs

Every operations manager I talk to has the same tab open: a SaaS pricing page. Somewhere between "Starter" and "Enterprise" is the plan that almost fits. The question they're really asking is whether "almost" is good enough, or whether it's time to build something of their own.

I build custom software for a living, so you might expect me to say "build". Often I don't. Here's the test I use.

Start with the honest default: buy

If a product fits how you work, buy it. Accounting, email, payroll, video calls, generic project management: these are solved problems. A good SaaS product has years of development behind it, a team fixing bugs and a price that's hard to beat for standard work.

Building your own version of a solved problem is how companies end up with expensive software nobody maintains.

When custom starts to make sense

Custom software earns its place when one or more of these is true.

Your workflow is the product

Made-to-order production, custom pricing per client, a booking flow with your own treatment and staff rules, a property business running several brands from one stock. When the way you work is what makes you better, a generic tool forces you to work like everyone else.

The real system is a spreadsheet

If the most important file in the company is a spreadsheet only one person understands, you already have custom software. It just has no permissions, no history and no backup plan. Replacing it is usually the best first project.

The same data is typed three times

Orders entered in the CRM, then in the production sheet, then in the invoicing tool. Every retype is time and a chance for error. Off-the-shelf tools often can't share data the way your process needs; a custom layer can.

Per-user pricing keeps growing

SaaS is cheap for five users and expensive for fifty, especially when most of them only need two screens. Custom software has no per-user fee. You pay for the build and the hosting.

You're bending the business around the tool

When people say "the system doesn't let us", and the workaround becomes the process, the tool is running the company instead of the other way round.

Compare five-year cost, not first-year price

The SaaS price is visible and the custom price is a single big number, so SaaS almost always looks cheaper in year one. Run the comparison over five years instead and include what's usually left out:

• Licences: per-user fees times the team you'll have, not the team you have today.
• Add-ons: the modules and integrations you'll need, priced at their real tier.
• Workarounds: the hours spent exporting, retyping and reconciling between tools.
• Errors: wrong orders, double bookings, missed follow-ups caused by data living in several places.
• Custom build: the first release plus the modules you'll add, and hosting.
• Changes: an optional monthly plan for small changes, or releases scoped as you grow.

Use your own numbers. Sometimes SaaS still wins clearly, and then you have your answer. When it doesn't, you have a business case your finance team can check.

What custom software actually costs

The worst way to build custom software is to specify everything up front and build it in one go. It takes months, costs a fortune and arrives out of date.

The way I work is releases. First, map the real workflow, including the parts that live in someone's head. Then scope the smallest system that removes the biggest problem. At Unlockd that first release starts from €6,900, at a fixed price, and reaches a working state in 3 to 4 weeks. Further modules follow, each with its own scope, price and date. I've written about why fixed prices beat hourly billing for exactly this kind of work.

For a small manufacturer, the first release is often catalogue, customers and orders. Production tracking with QR or NFC tags comes next, then shipping. For a spa, it's booking and reminders, then the till and vouchers. You start getting value in weeks instead of waiting a year for the whole system.

The hybrid most companies end up with

In practice the answer is rarely all or nothing. Most of the systems I build sit next to bought tools:

• accounting stays in the accounting software, connected by integration;
• email and calendars stay where they are;
• WhatsApp messages go through Meta's official platform;
• payments go through a payment provider;
• the custom part covers what makes the business different: orders, production, bookings, listings, clients.

That keeps the custom part small, focused and cheaper to maintain.

The risks, and how to reduce them

Custom software has real risks. Most come from how it's commissioned, not from the code.

1. Building too much at once. Fix it with small releases.
2. Depending on one person who never documents anything. Insist on a standard stack, documentation and code in your own repository. I build in Next.js, React, Prisma and PostgreSQL precisely because any competent developer can pick it up (why we chose that stack).
3. Not owning the result. The code, database and hosting accounts should be in your company's name from day one.
4. Building something nobody uses. Pilot each release with the people who'll use it every day, then correct it against reality. Tools that tell people what to do next get used; dashboards that only show numbers rarely do.

A quick test

Score each statement 0 (no) to 2 (very much):

• We retype the same data in more than one place.
• A spreadsheet is our real system.
• Our per-user software costs grow every year.
• Our workflow is part of why customers choose us.
• We've built workarounds around the tool we pay for.

Under 4: buy, and configure it well. Between 4 and 7: look at a custom layer connecting your tools. Above 7: a custom first release will probably pay for itself.

If you'd like a second opinion, describe the process that costs you the most time. I'll tell you honestly whether it needs custom software or a tool you can simply buy, and for manufacturers in particular, what a sensible first release would cover.