Build vs Buy Software: A Framework With Three Real Answers

Sooner or later most business owners face a version of the same question: should we buy this software or have someone build it? The build vs buy software decision usually gets made on gut feel, a demo that landed well, or a quote that came in under budget. A year or two later the tool is half-used and someone keeps a spreadsheet beside it to cover the gaps.

The call is easier than it looks, but only if you stop treating it as a coin flip. There are three answers, not two. Buy when the problem is common. Integrate when the gap sits between systems you already own. Build only when the logic is genuinely yours. Most companies never seriously weigh the middle option, because nobody shows up to sell it.

Buy When the Problem Is Common

If ten thousand other companies have the exact problem you have, someone has already built better software for it than you will ever fund. Accounting, payroll, email, CRM, help desk, storefront checkout, appointment scheduling: buy these. A vendor serving that entire market can spend more on the product than you could ever justify spending on your own.

The test is not whether the product is perfect. The test is whether your version of the problem differs in a way that shows up for your customer or in your margin. Wanting a different button layout is not that kind of difference. Wanting a pricing rule no vendor supports might be.

Buy first when most of these are true:

• The process is standardized by someone other than you: tax rules, payroll filings, shipping labels, card processing
• Off-the-shelf products already cover the great majority of the workflow without workarounds
• The category has several mature competitors, which keeps pricing honest and exports possible
• You can pull your own data out in a documented format any day you decide to leave
• Total seat cost over three years lands well under what an equivalent build plus upkeep would run

That last point gets missed in both directions. A tool at $400 a month is $14,400 over three years. If the custom equivalent is a $60,000 build plus annual maintenance, buying wins on arithmetic alone unless the product actively blocks revenue.

Integrate When the Gap Is Between Systems

Here is the option almost nobody raises during a build or buy decision. Your accounting package is fine. Your CRM is fine. Your online store is fine. What is broken is the space between them, where a person retypes order numbers from one screen into another every morning at nine.

Nobody sells you that fix because it is not a product. It is plumbing. Vendors sell what they own, and the space between two vendors belongs to neither of them. So the gap stays open while everyone argues about replacing systems that work. Ask the person doing the copying how many minutes it takes each day. That number, multiplied out over a year, is your integration budget.

What Integration Actually Replaces

A request that arrives as “we need custom software” is often an integration request in a costume. The symptoms are specific: double entry, a nightly export, a spreadsheet that reconciles two systems, an employee whose real job is moving data. All of those get fixed by connecting the systems you already pay for instead of replacing any of them.

Integration also costs less than a rebuild. A well-scoped sync between two APIs is usually measured in weeks rather than quarters, and it leaves both vendors in place. If one tool stops earning its keep later, you swap that piece rather than unwinding an entire platform.

When Integration Is Not Enough

Integration falls apart when there is no system of record to connect to, when a vendor’s API is undocumented or read-only, or when the workflow itself lives in no tool you own. If two of those are true, you are looking at a build after all. Read the API documentation before anyone writes a proposal, not after.

Build Only When the Logic Is Genuinely Yours

Custom is right when the thing you do is the thing you sell. If your pricing model, your routing rules, your inspection workflow, or your client portal is the reason people choose you over the shop down the street, that logic should not sit inside someone else’s product roadmap.

Good candidates for custom software shaped around your process share a pattern. They are narrow, they get used daily, and they are worth real money when they work.

• Client portals where customers check status, approve work, and pay without calling you
• Quoting or configuration tools that encode rules only your estimators carry in their heads
• Internal tools that retire a spreadsheet ten people fight over
• Field and mobile apps used in places with bad connectivity or specific hardware
• APIs that let partners and customers transact with you programmatically
• AI features that read your documents and your history, where the value comes from your data rather than the model

Notice what is absent from that list: anything a category leader already sells. Nobody should build a CRM. Plenty of companies should build the one screen their salespeople live in all day and let it read from the CRM they bought.

The short version of the build test: if a competitor could buy your workflow off a shelf tomorrow, do not pay to have it built.

Off the Shelf vs Custom Software: The Costs Nobody Quotes

That comparison usually gets framed as license fees against a project quote, which hides the two numbers that actually decide it.

The first is the workaround tax. Every step your bought tool cannot handle becomes a manual step, and manual steps have salaries attached. Twenty minutes a day across four employees is more than 300 hours a year. Price that before you call a license cheap.

The second is upkeep. Custom software is not a purchase. It is a pet. A common rule of thumb is 15 to 20 percent of the original build cost per year for hosting, dependency updates, browser and operating system changes, and small fixes. A budget without that line is a budget for an app nobody maintains.

Put both numbers on one page and the winner is usually obvious. What burns companies is comparing a three-year license total against a one-time build quote and pretending the second number is finished.

A One-Week Process for the Build or Buy Decision

Most build vs buy decisions can be made in five working days. You do not need a three-month evaluation. You need honest answers written down where everyone can see them.

• Day 1: Write the workflow as it happens today, spreadsheets and email threads included. If nobody can fit it on one page, that confusion is your real problem.
• Day 2: Shop the market. Score the top three products against that written workflow and mark every step that needs a workaround.
• Day 3: List the systems you already own and decide whether the gaps sit inside one tool or between tools.
• Day 4: Price all three paths across 36 months: licenses plus workaround hours, integration plus licenses, build plus maintenance.
• Day 5: Choose the cheapest path that does not cap your growth plan, and write down what would change your mind.

Run that week honestly and the answer is often “buy two products and connect them.” Sometimes it ends in an Odoo ERP implementation, because the four tools you planned to wire together belong in one system anyway. Occasionally it ends in a real build, and by then you can defend the number to anyone who asks.

The Answer That Costs Us Money

We turn down build projects. A company asks for a portal, and sometimes the honest answer is that an existing product plus a couple of days of setup gets them there. Saying so costs us the project, and it is still the right answer.

Be suspicious of any firm whose recommendation always matches its highest-margin service. Shops that only build will find a reason to build. Shops that only resell will find a reason to resell. The build vs buy software question has three legitimate answers, and a partner who arrives at the same one every time is not answering your question.

Want a Straight Answer on Build vs Buy Software?

Bring us the workflow, not the wish list. We will tell you which of the three paths fits, what it costs across three years, and where the maintenance lands. If buying is the right move, we will name the products and stay out of your way.

Parameter builds portals, internal tools, mobile apps, APIs, and integrations, and we run WordPress and Odoo operations for companies that would rather not think about either. Tell us what is broken through our contact page and we will start with the diagnosis instead of the quote.