Custom software vs off-the-shelf: how to decide without wasting money

There's a spreadsheet running your business somewhere. Twelve sheets, four people editing it, colour coding one person fully understands. It works, in the sense that the business runs. It also can't be audited, breaks quietly, and only one person can fix it.

The question is whether to replace it with a product you buy or software you build. Both answers are right in different circumstances, and the cost of choosing wrong is high in both directions — an unnecessary custom build burns money you didn't need to spend, while forcing a product onto a process it doesn't fit destroys the thing that made the process work.

The test

Ask one question about the process you're trying to systematise:

Is this process part of why customers choose us, or is it just how we happen to do something everyone does?

Payroll is not why customers choose you. Neither is accounting, email, or storing files. These are solved problems with mature products, and building your own version is a waste of money and an ongoing maintenance liability.

But the way you price a complex quote, schedule production around machine availability, allocate stock across branches, or route an approval through three departments — that might genuinely be yours. If it's the reason you deliver faster or cheaper than the competition, bending it to fit a product means giving up your advantage to save on software.

A more concrete version of the test

Try to find three products that do what you need. Then check:

• How much of what you need do they cover? If it's 80% or more and the missing 20% isn't competitively important, buy one and adapt.
• How much of the product would you use? Paying enterprise licensing to use 10% of a large platform is a common and expensive mistake.
• What does the missing 20% cost you? If the workaround is one person spending an hour a week, live with it. If it's three people spending half their day, that's the business case for building.
• How many people need it? Per-seat pricing across fifty users changes the arithmetic considerably compared to five.

Where off-the-shelf clearly wins

• Accounting and compliance. Tally, Zoho Books, and similar handle GST filing and change when regulations change. You do not want to own that maintenance burden.
• Email, files, and calendars. Solved. Buy.
• CRM, for standard sales processes. If your pipeline is enquiry → quote → follow-up → close, a product does this well.
• E-commerce, for standard retail. A hosted storefront gets you selling in days.
• Payroll and HR. Regulatory changes are somebody else's problem, and that's worth paying for.

The general rule: if the process is governed by external rules that change without your input, buy it. Somebody else maintaining compliance is worth more than any customisation you'd gain.

Where custom genuinely earns its cost

• The process is your competitive advantage. Quoting logic, scheduling rules, pricing models specific to your business.
• You've outgrown a spreadsheet but no product matches. Common in manufacturing, distribution, and specialised services.
• You need systems to talk to each other. Often the real problem isn't any single system but that data is entered three times because nothing connects.
• The volume of manual work is scaling with growth. If doubling orders means doubling admin staff, software has a clear payback.
• You're paying for a large platform to use a fraction of it. At a certain point building the fraction is cheaper.

The answer that suits most businesses: both

Presenting this as a binary choice is where most of the money gets wasted. What usually works is:

Buy the commodity parts. Build the specific part. Connect them.

In practice, for a mid-sized manufacturer that might look like:

• Tally continues handling accounts and GST. Nobody learns a new accounting package.
• A custom system handles production scheduling and job tracking — the part that's actually theirs.
• The custom system pushes completed jobs into Tally as invoices automatically.
• A customer portal, built on the same data, lets clients check order status without phoning.

The custom build stays small enough to finish and cheap enough to justify. The compliance burden stays with vendors who specialise in it. And nobody is retyping invoice data.

What custom software actually costs

Two numbers matter, and people usually only think about the first.

Build cost is quoted per phase. A first phase replacing one significant manual process is meaningfully more than a website but far less than a full platform. Phasing matters: each phase should deliver something usable, so you can stop after phase one if the return isn't there.

Ongoing cost is the one that gets forgotten. Custom software needs hosting, monitoring, backups, occasional dependency updates, and changes as your process evolves. Budget an annual figure for this from the start. Software that nobody maintains becomes the thing you're trying to replace in four years.

Against that, weigh what the current situation costs — staff hours on manual entry, errors caught late, the risk concentrated in one person's spreadsheet, and the growth you can't take on. That comparison, not the build quote in isolation, is the actual decision.

Three failure patterns to avoid

Building too much at once. The single most common cause of failure. A system that tries to replace six processes simultaneously takes a year, and requirements change underneath it. Replace the worst one first.

Getting the data model wrong. Screens are cheap to change; the underlying data structure is not. Spending an extra week getting entities and relationships right is the highest-return time in the project.

Not involving the people who do the work. If the new system is slower than the workaround it replaces, people go back to the spreadsheet and no amount of training fixes it. The people doing the work know where the exceptions are — they need to be in the design conversation, not just the training session.

A reasonable way to start

Don't start with a build. Start with a written map of the current process — the real sequence, including the workarounds everyone relies on. That document alone usually reveals that a third of what people asked for is a symptom of something simpler.

From there the buy-versus-build decision is usually obvious, and it's frequently "buy this, build that, connect them."

If you'd like help making that call, tell us about the process that's held together manually. We'll give you a straight recommendation — including when it's to buy a product and not hire us.