Build vs buy software: how to decide

Buy off the shelf when

For most business functions, buying is the right answer. Someone else has already built, tested and documented the software, and thousands of other companies are paying to keep it improving. Accounting, payroll, email, video calls and basic e-commerce are good examples: the way you do them is not what sets you apart, so there is little reason to own the code.

Buying usually wins when:

• Your process is close to how most businesses in your field work, and you would be happy to adjust it slightly.
• A tool covers most of what you need today, and the gaps are minor or can wait.
• You need something running this week, not in a couple of months.
• The software is regulated or specialized in a way the vendor already handles, such as tax filing or payroll compliance.
• You are still figuring out your process and expect it to change a lot over the next year.
• The total cost of the subscription over several years is small compared with what a build would cost.

Build custom when

• The software is part of what you sell or how you deliver it, so matching a competitor’s tool means matching your competitor.
• Your team keeps spreadsheets or paper on the side because the tool cannot do a key step.
• You are paying for three or four tools and moving data between them by hand.
• Per-seat or per-record pricing grows faster than your revenue as you hire.
• You need clients, vendors or field staff to log in and see something the tool was never designed to show them.
• You have looked hard and no product handles your rules, your industry or your integrations.
• You want to own the data, the code and the roadmap instead of waiting on a vendor’s priorities.

The real costs on each side

People often compare a monthly subscription with a one-time build quote and stop there. That comparison misses most of the cost on both sides.

On the buy side, add up the subscription for every user you expect to have in three years, the add-ons and higher tiers you will likely need, the time spent on workarounds, any integration tools you pay for to connect it to everything else, and the cost of switching later if the vendor raises prices or drops a feature.

On the build side, add the initial design and development, hosting, ongoing fixes and changes, and the time your team spends explaining the process and reviewing work. Custom software is never finished, so budget for it to keep changing. A build that looks cheaper on day one can cost more by year three if nobody plans for upkeep, and a subscription that looks cheap can quietly become one of your largest software bills.

How to make the build vs buy software decision

1. Write down the processList every step, who does it, what data it needs and what happens next, before you look at any product.
2. Mark what is uniqueCircle the steps that make you different from competitors. Everything else is a candidate to buy.
3. Test two or three tools for realRun a free trial with your actual data and the people who will use it, not a sales demo.
4. List the gapsFor each tool, note what it cannot do and how you would work around it. Be honest about how painful each gap is.
5. Price it over three yearsCompare total cost on both sides, including seats, add-ons, workarounds, upkeep and switching costs.
6. Decide piece by pieceBuy where a tool fits, build where it does not, and plan how the pieces will share data.

The middle path: buy, then extend

Build vs buy is rarely all or nothing. A common pattern is to keep a well-known tool for the parts it does well and build a smaller custom piece around it: a client portal that reads from your CRM, an app for field staff that writes jobs into your accounting software, or an automation that moves data between systems so nobody has to copy and paste.

This keeps the build small, focused and cheaper, and you only own code for the part of the business that actually needs it. The trade-off is that you depend on the tool’s API, so check what it allows before you commit.

When not to build custom

Building is the wrong choice more often than people who sell custom software like to admit. Hold off if you have not yet tried the leading tools properly, if your process is still changing every month, if you have no budget for upkeep after launch, or if the main reason is that you dislike one screen in an otherwise fine product. In those cases, buy something, live with it for a while, and come back to the question once you know exactly where it falls short.