When to Build Custom Software: A Decision Tree
Date Published
Build custom software when a process is genuinely yours, no off-the-shelf tool covers it without workarounds, and you have the runway to use it for years. Buy when a standard tool already fits, or when the process is common to every business in your industry. Everything else is a judgment call, and that judgment call is what this article walks you through.
Our main guide to custom software development covers cost, process, and timelines end to end; this piece is the deep dive on one question from that guide, when to build custom software instead of subscribing to something that almost fits. What follows is a decision tree you can actually run against your own situation, five scenarios pulled from real build-or-buy calls, and an honest list of reasons to wait.
The Build vs. Buy Decision Tree: Four Questions in Order
Work through these in sequence. Each question either ends the decision or passes you to the next one. Skipping ahead is how companies talk themselves into builds they didn't need, or subscriptions that quietly cost them for years.
Question 1: Is this a commodity process?
Payroll, accounting, email, calendaring, and basic accounting are solved problems. Every company needs them, and they work the same way at almost every company. If your answer is yes, stop here and buy. No custom build beats a mature product on a process nobody differentiates on.
If the process is specific to how your business actually operates, move to question two.
Question 2: Does an off-the-shelf tool cover 90% or more of it, cleanly?
Not "cover it if we adjust our process to match the software." Cover it as your process already runs, without a parallel spreadsheet, a manual export-and-reformat step, or a workaround someone maintains from memory. If a tool genuinely gets you there, buy it and move on. A thin custom layer bolted onto a 90%-fit product is often cheaper than a full build, and worth scoping separately.
If the gap is the workaround itself, the double entry, the manual patch step, move to question three.
Question 3: Is this process your competitive edge?
Some gaps are annoying but invisible to your customers. Others are the exact thing that makes a customer pick you over the next vendor: your quote turnaround, your fulfillment accuracy, your ability to handle an exception a competitor's software chokes on. If the gap sits somewhere nobody but your ops team ever notices, lean toward buying anyway, or trying a low-code layer first. If the gap sits on the process that wins you business, move to question four.
Question 4: Do you have three or more years of runway to use this?
A custom build is a multi-year asset, not a one-time purchase. It has to earn back its cost against the workaround it replaces, and that math needs time to run. If your team, your process, or your company's direction is likely to change substantially within a year or two, the answer here is not yet, not never. If the process will still exist in roughly its current shape for three years or more, build.
Pass all four gates and the decision is build. Fail any one of them and the honest answer is buy, wait, or patch with a low-code layer. The scenarios below show how this plays out on real requests.
Five Scenarios: What the Tree Says in Practice
Scenario 1: A distributor's tiered pricing quote tool. Verdict: build. A 40-person distributor quotes each customer against tiered volume discounts, customer-specific exceptions, and freight surcharges that change by lane. No commodity CPQ tool models all three together without a maintained spreadsheet behind it. The gap is the spreadsheet: two people update it by hand, and a wrong tier costs margin on every order it touches. Quoting speed and accuracy is the thing customers actually notice, so this is a competitive-edge process with three-plus years of life left in it. Build.
Scenario 2: Payroll and time tracking for a 15-person agency. Verdict: buy. Nothing about how this agency runs payroll differs from any other 15-person company. A mainstream payroll platform covers tax filing, direct deposit, and time tracking completely, with no workaround needed. This fails question one outright. Buying here is not a compromise; it is the correct answer, and the money saved belongs in the process that actually differentiates the business.
Scenario 3: An internal reporting dashboard pulling from four SaaS tools. Verdict: not yet, use low-code. An operations team wants one dashboard instead of four logins. The reporting need is real, but nobody is sure yet which metrics will matter once the team restructures next quarter, and the underlying SaaS tools themselves might change. This clears question two (no off-the-shelf dashboard covers a bespoke four-tool blend) but stalls on question four: the runway is uncertain. A low-code platform (Retool, Power Apps, and similar tools sit in a market Gartner projects to keep growing toward $44.5 billion by 2026) gets a working dashboard live in days and can be rebuilt cheaply once the team's shape settles. Revisit a custom build once the reporting requirements hold still for two straight quarters.
Scenario 4: A logistics dispatch board for a mixed fleet. Verdict: build. A regional carrier runs a standard transportation management system that handles single-mode dispatch well, but breaks down on the multi-modal exceptions their fleet hits daily: a load that switches from truck to rail mid-route, a driver swap that the software can't represent without a manual note. Dispatch accuracy is the company's actual differentiator against larger competitors with less flexible routes. The fleet composition is not changing soon. Every gate passes. Build.
Scenario 5: A customer portal for a two-person, pre-revenue startup. Verdict: not yet. A founder wants a polished customer portal before the product has paying customers to validate which features that portal even needs. The requirements are still moving weekly, nobody has run the actual customer workflow long enough to describe it precisely, and there's no revenue yet to fund three years of use. This fails question four for a structural reason: there's no stable process to amortize a build against. A free-tier tool or a simple form gets early customers through the door; build the real portal once the workflow stops changing every sprint.
Signs You Should Not Build Custom Software Yet
A guide that only tells you when to build isn't being straight with you. Some of the clearest build signals turn out to be premature once you look closer.
- You can't describe the process in one page yet. If writing down "how quoting should work" surfaces disagreement on your own team, custom software will encode that disagreement permanently, not resolve it. Settle the process on paper first, even in a spreadsheet, before paying to encode it in software.
- You're building because a competitor built something, not because of your own pain. Copying a competitor's tool without your own workaround, your own cost, and your own customer complaint behind it usually means you're solving their problem, not yours. Find your own version of the gap before you commission a fix for it.
- The workaround hasn't cost you anything you can point to. "This annoys us" is not the same as "this costs twelve hours a week and a wrong invoice every month." If you can't name the cost, you likely can't justify the build yet either. Track the cost for a month; the number either justifies the project or talks you out of it.
- Nobody on your team, or your vendor's, owns what happens after launch. Software needs a person who fields the next feature request, watches for the next integration that breaks, and decides what changes and what doesn't. A build with no owner on either side degrades quietly until nobody trusts it.
If two or more of these describe your situation, wait. Fix the cheaper problem (the process, the cost visibility, the ownership question) before you fix the expensive one.
Frequently Asked Questions About Build vs. Buy Decisions
How do I know if I should build custom software or buy it?
Buy if a standard tool covers your process without workarounds, or the process is common to every business. Build once your process is specific to you, the gap is expensive, the process is your competitive edge, and it will hold its current shape for three or more years.
What is the build vs. buy decision framework?
It's a sequence of four questions: is the process a commodity, does an off-the-shelf tool cover it cleanly, is it your competitive edge, and do you have three or more years to use it. Build only if every question points toward build; any single no points toward buy or wait.
Is custom software always more expensive than buying software?
Not over time. A subscription looks cheaper month to month, but stacked across several tools for three years it often exceeds a fixed-price custom build, especially once per-seat fees and workaround labor are counted. The upfront number and the three-year number frequently point in different directions.
How long should I wait before building custom software?
Wait until the process you want to encode has held roughly the same shape for a couple of quarters, and until you can name a specific cost the current workaround creates. Building against a process that's still changing weekly usually means rebuilding within a year.
Can I start with off-the-shelf software and switch to custom later?
Yes, and it's often the right sequence. Off-the-shelf or low-code tools validate that a process is worth building for, cheaply and fast. Once the workaround cost is clear and the process has stabilized, a custom build replaces the stopgap with something shaped exactly to how you actually work.
Run Your Own Situation Through This Tree
Describe the process, the tool you're using today, and where the workaround shows up, and we'll tell you honestly which side of the tree you land on. If it's a build, you'll get a fixed scope, a fixed-price package, and a delivery date measured in weeks, scoped the way we describe on how we scope, build, and review. If it's a buy, we'll say so.