Custom Software vs Off-the-Shelf: Which Is Right for Your Business?

I get this question almost every month: “Should we just buy something, or should we build?”

People expect a religious answer. Custom is “serious.” Off-the-shelf is “for people who aren't ready.” That's nonsense. I've told companies to buy. I've told founders not to write a line of code. I've also told people that the SaaS they are paying $800 a month for is already more expensive than a focused custom system — because of the staff time around it.

The right choice is not a personality. It's whether your process is common or your process is the business.

What Off-the-Shelf Actually Is

Off-the-shelf (packaged SaaS, ERP modules, industry templates) is software designed for a crowd. Accounting. Email. Helpdesk. A generic CRM. Payroll in a normal country with a normal tax year.

You rent someone else's model of work. That's a gift when your work looks like everyone else's. You get updates, security patches, a mobile app, and a support page. You also get their assumptions: their fields, their statuses, their idea of a “customer.”

When those assumptions match you, buy it and go home. I mean that. A software consultant who always recommends custom is selling hours, not advice.

What Custom Actually Is

Custom is not “we invented a new database for fun.” Custom is software shaped around a workflow that packaged tools keep fighting.

Examples I see: a B2B pricing engine with exceptions nobody's CRM will store without five custom objects and a consultant on retainers. A field operation where the job isn't “a ticket,” it's a sequence of checks that have to happen in order, offline, with photos. An internal ops platform that replaced four spreadsheets and a group chat — that's the case study shape on my site.

You own the model. You also own the maintenance. That's the trade. If you are not ready to own it, don't commission it. Hire a software consultant first, not a team of builders.

A Straight Comparison

Buy Off-the-Shelf When…

• The job is a commodity: books, email, video calls, basic HR.
• A well-known product already has your industry's language and you can live with 80% fit.
• You need to start next week, and “pretty close” is better than “perfect in five months.”
• You do not have anyone who will own a custom codebase after launch.

If you're a founder still validating demand, I would rather you use no-code or a cheap SaaS than invent a platform. I covered a cousin of this in no-code vs custom SaaS. Same instinct: don't carve marble before you know it's a statue.

Build Custom When…

• You already outgrew the packaged tool. Read when a business has outgrown its software.
• Your margin comes from a workflow competitors don't have — and the SaaS is sanding that edge off.
• You are paying two extra people to feed the official system. That's a build vs buy math problem, not a vibe.
• Integrations have become a career. Five tools, four Zapier zaps, one person who understands them. That's not “being modern.” That's a fragile company.

The Answer I Give Most Often: Mix

Buy identity, payments, email, accounting. Build the operational core — the thing your customer actually pays you to do well.

Teams get religious: “We're an all-custom shop” or “We only use best-of-breed SaaS.” Both are identities. Businesses need a map. That map is requirements and architecture, not a Twitter argument about stacks.

Think in Three Years, Not in the Demo

Off-the-shelf looks cheap because you compare licence to a development quote. That's the wrong comparison. Compare three years of licence + seats + implementation partners + staff time feeding the tool against a scoped custom core + hosting + someone who can maintain it.

I have seen a packaged “industry solution” that needed four extra modules, a specialist on call, and two staff whose job was to make the software resemble the company's actual pricing. On paper they “didn't build.” In cash they built a shadow system around a product they didn't own.

I have also seen a company insist on custom CRM when HubSpot or a simple tool would have been fine — because the founder wanted “our own platform.” That's ego with a GitHub repo. Your customer does not care that you invented another contacts table.

Three-year thinking kills both fantasies. If the unique workflow is small, buy. If the unique workflow is how you make money, stop pretending a generic CRM will grow a spine.

Two Mistakes I See Constantly

Mistake one: custom too early. You don't know the process yet, so you encode confusion. Six months later you have expensive confusion. That's the wrong product with nicer hosting.

Mistake two: off-the-shelf forever out of fear. You keep buying modules. You hire implementation partners. You still run Excel beside it. Three years later you've spent a custom budget and you own nothing.

A Decision You Can Make This Week

Write one page:

1. What is the workflow that makes us money?
2. Which steps are generic (invoice, email) vs unique (how we price, route, approve, deliver)?
3. What have we already paid in people-time to force a packaged tool to behave?
4. What would version one of a custom core not include?

If you cannot fill that page, don't buy a six-month build. Book consulting. If the page is clear and the unique part is small, buy. If the unique part is the company, we talk about a technical partnership after the blueprint.

I work this remotely from Port Harcourt with companies in the US, UK, Canada, and Nigeria. I don't take equity. I will tell you to buy if that's the grown-up answer.