Build vs Buy Software: How to Decide, With the Real Costs

Buy software for anything that works the same at every company, and build only what makes your business different. Accounting, email and payroll are solved problems. Custom software earns its cost when the workflow is your edge, the off-the-shelf tool forces expensive workarounds, or integration and per-seat costs overtake what a build would cost over three to five years.

You're probably here from one of two directions. Either you're paying for a stack of subscriptions, your staff copy data between them all day, and someone has said "we should just build our own." Or a developer has proposed building something you suspect you could subscribe to tomorrow.

Both can be right. Both can be very expensive mistakes.

I sit on both sides of this. I build software people buy, and I build custom software for companies that shouldn't buy it. So I've seen both bills, and I've told plenty of people not to build. What I care about is the number at the end of year three.

Why "build or buy?" is the wrong first question

The first question is what job the software has to do, and whether that job is the same at every company or particular to yours.

A client once came to me with budget already approved for iPhone and Android apps. When we listed what their customers actually needed to do, none of it required an app store. I told them not to build it, and we shipped a responsive web app with PWA features instead. The story is in PWA vs Mobile App.

That wasn't a build-vs-buy decision on paper, but it's the same discipline. The cheapest software is the software you never have to build or pay for. Before comparing vendors and quotes, strip the request back to the outcome you need.

When should you buy off-the-shelf software?

Buy when the function is a commodity: it works roughly the same way at every company, and doing it differently gives you no advantage.

• Accounting, payroll and tax. The rules change constantly and the vendor carries the cost of keeping up.
• Email, calendars, file storage and chat. Nobody chooses you because of your email server.
• HR, expenses and standard CRM. If your sales process looks like everyone else's, a mainstream tool fits it.
• Anything you need running this month. A subscription works on day one. A build doesn't.
• Anything with a small number of users where per-seat pricing stays modest.

If your process should look like everyone else's, buy, and adapt the process to the tool. That's not a compromise. Mainstream tools encode a lot of other people's hard lessons.

When does custom software make sense?

Build when the software is part of what makes you different, or when buying has quietly become the expensive option.

1. The workflow is your differentiator. If the way you schedule, quote, inspect or deliver is why customers pick you, forcing it into a generic tool sands off your edge.
2. The tool forces painful workarounds. Spreadsheets on the side, the same data typed into two systems, a person whose job is mostly reconciling. I wrote about that tipping point in Outgrowing Excel.
3. Integration costs exceed build costs. When you're paying for three tools, plus connectors between them, plus someone to fix the sync when it breaks, one purpose-built system can cost less.
4. Per-seat pricing at scale. A price that's trivial at ten users can become one of your largest software lines at a few hundred.
5. The software is the product. If you plan to let customers use it, or sell it, you need to own it. Ridgeline Engineering's internal tool became TowerSight, a multi-tenant platform its customers run themselves. You can't do that on someone else's subscription.

Not sure your workflow is different enough to justify a build? A clickable prototype will tell you faster than a spec. Once your team has clicked through it, the answer is usually obvious.

The third option: buy the core, build the thin layer

This is the answer most often missed, and it's usually the right one.

Buy the commodity core, then build a thin custom layer where your business is different: an integration that moves data between your accounting system and your operations tool, a customer portal on top of a CRM, a dashboard that pulls from three systems into one view.

Two rules keep the hybrid healthy. Keep the custom layer thin, so a vendor upgrade doesn't break a mountain of code. And use the vendor's official API and export, never screen-scraping or database hacks that break silently.

What does build vs buy really cost over 3 to 5 years?

Compare total cost of ownership over three to five years, not this year's subscription against a build quote. Here's what belongs on each side:

A few lines deserve extra attention.

Maintenance is the line people forget on the build side. Across the life of a system, keeping it running and up to date usually costs more than building it in the first place. If a build proposal has no maintenance line, it's incomplete. That's one of the things to check in how to evaluate a software development estimate.

Workarounds are the line people forget on the buy side. Nobody invoices you for the hours your team spends copying data from one system to another. Count them for a typical week, multiply by what those people cost you, and put it in the buy column.

Recurring costs compound. For eight years I ran a P&L covering development, support and hosting. The hosting department went from break-even to over 40% gross margin by migrating more than 100 sites to a cheaper platform and onboarding 75 clients. Nobody wrote clever new software for that. A big part of the win was sitting in a recurring cost line that hadn't been re-examined. Your software subscriptions deserve the same look every year.

What are the hidden costs of each option?

Hidden costs of buying:

• Vendor lock-in. The longer you use a tool, the more of your process and data take its shape, and the more leaving costs.
• Data ownership. Check that you can export everything, in a usable format, without a support ticket.
• Price and plan changes. The vendor sets the price at renewal, and features can move to a higher tier.
• Roadmap risk. The feature you need may never come, and the one you rely on may be retired.

Hidden costs of building:

• You own every bug and every security patch, for as long as the software runs.
• The bus factor. If one developer understands the system, losing them is a crisis. Insist on documentation, tests and code you can hand to someone else.
• Estimates slip. Data migration, integrations, login and permissions, and testing are where custom builds run over.
• It ages. Five or ten years on, custom software faces its own decision: rebuild or refactor. Budget for upgrades as you go and that decision gets much cheaper.

How do you decide? Six questions

Work through these for each piece of software you're weighing:

1. Is this the same at every company in my industry? If yes, buy.
2. Would customers notice if we did it differently? If yes, it's a build candidate.
3. What are the workarounds costing? Count the staff hours for a normal week. Don't guess.
4. What's the three-to-five-year total, both ways? Use the table above, including maintenance and switching costs.
5. Can we get our data out? If not, the buy option carries more risk than its price suggests.
6. Who maintains it in year three? If you can't name a person or a firm, you aren't ready to build.

If the answers point in different directions, that's usually the hybrid telling you it's the answer: buy the standard part, build the part that's yours.

Click through it before you commit to building

The biggest risk in a build is spending months on the wrong thing. A clickable prototype shrinks that risk: your team taps through real screens with sample data and settles what the product should be before any production code is written. If the prototype shows that an off-the-shelf tool would do the job, you've lost days, not a budget. If it shows the build is right, sign it off as the agreed scope, and every quote you collect prices the same thing.

Every custom build I take on starts this way. You can click through six working prototypes, including a bookkeeping app, a membership portal and a rental management app, with one-click sign-ins for each role.

Get a second opinion before you sign either way

Build vs buy is a decision you live with for years, and the people pitching each side rarely have an incentive to tell you about the other.

This is exactly what a Technical Assessment covers: I look at your current tools, your workflows and the proposals in front of you, then give you a written recommendation on what to buy, what to build and what to connect, with the three-to-five-year cost of each path.

FAQ

Related Reading

• Rebuild vs Refactor: How to Decide Whether to Rewrite Legacy Software: What to do when the custom software you built years ago starts to age.

• How to Evaluate a Software Development Estimate (Before You Sign): How to tell whether a build quote holds up, and which line items are usually missing.

• Outgrowing Excel: Why Web Apps Transform Business Operations: The signs your spreadsheets have become the expensive option.

If you're about to sign a long subscription or approve a custom build, check the three-to-five-year numbers first. Get in touch if you want someone with no stake in either option to run them with you.