I don’t recommend that clients choose between buying software and building it as a one-time decision made in a single meeting. The businesses that get this right treat it as a sequence: buy first, learn from real use, then decide whether building is warranted. This piece walks through that sequence and how to know when you’ve moved from one stage to the next.
Why Sequencing Beats a One-Time Decision
The problem with deciding build-vs-buy up front is that you’re deciding without data. You don’t yet know exactly where a packaged tool will fall short for your specific workflow, because you haven’t run your specific workflow through it yet. Every business believes its needs are unique before it starts using a tool. Most find that 80–90% of what they assumed was unique is actually well covered by existing software, and the real gaps are narrower and more specific than expected.
Buying first is how you find out which 10–20% is genuinely a problem, without paying custom-development prices to discover it.
Stage One: Buy and Actually Use It Hard
The first stage isn’t just purchasing a tool — it’s running your real workflow through it for long enough to hit its edges. This usually takes 6–12 months of genuine use, not a trial period. Configure it reasonably, but resist the urge to over-customize immediately. The goal at this stage is to learn where the tool fits and where it doesn’t, not to force it to fit everywhere through heavy configuration, which is how businesses fall into what I call the configuration trap — spending consultant money making a platform do things it was never built to do well.
Keep a running list during this stage of every workaround your team builds. That list is the raw material for stage two.
Stage Two: Quantify What’s Actually Broken
Once you have a real list of workarounds, the second stage is quantifying them. How many hours a week does each workaround cost, across how many people? What’s the dollar value of leads lost to a reporting gap, or invoices delayed because two systems don’t talk to each other? This is the point where vague frustration ("this software is annoying") turns into a business case ("this software costs us roughly $4,000 a month in staff time and missed follow-up").
I’ve written a full framework for running these numbers, including a 3-year comparison structure, in The Real Cost of Software Ownership. That piece is worth working through at this stage — it’s the difference between a hunch and a decision you can defend to a partner or a board.
Stage Three: Check for the Signs, Not Just the Cost
Cost is one input, but it’s not the only signal that you’ve outgrown a packaged tool. There’s a set of more concrete operational signs worth checking alongside the cost math — things like a single person being the only one who understands your configuration, or your team building spreadsheet workarounds that duplicate what the software should already do. I cover those signs specifically in Signs You’ve Outgrown Off-the-Shelf Software, and it’s worth reading alongside your cost numbers before you commit to a direction.
Stage Four: Decide, and Decide Honestly
By the time you’ve run stages one through three, the decision is usually clearer than it was at the start. Sometimes the answer is that the current tool, better configured or paired with a better vendor, still makes sense — in which case a rigorous vendor evaluation is the next step, which I cover in How to Evaluate Software Vendors. Sometimes the answer is a hybrid: keep the platform for what it does well and build a custom layer against its API for the specific gaps. And sometimes the answer is a full custom build, when the three conditions I look for — a genuinely non-standard workflow, a quantifiable cost of the workaround, and a stable enough process to build on — are all true at once.
I walk through those three conditions, and the broader case for buying first in general, in Build vs Buy: When Custom Software Is Worth It, which is the right starting point if you haven’t read it yet.
What Businesses Get Wrong About This Sequence
The most common mistake I see isn’t skipping stage one — most businesses do buy first, by default. It’s skipping stage two: they feel frustrated, but they never quantify it, so the decision to build (or not) ends up made on emotion rather than numbers. The second most common mistake is skipping stage three and jumping straight from cost frustration to a development contract, without checking whether a better vendor or a smarter configuration would solve the problem for a fraction of the cost.
A third mistake, less common but more expensive when it happens, is running the sequence correctly and then ignoring the result. I’ve had clients complete a genuinely rigorous cost analysis, land clearly on "stay with the packaged tool and switch vendors," and then commission a custom build anyway because a build felt like the more decisive, more impressive move. Custom software is not a status symbol. It’s infrastructure, and infrastructure decisions should follow the numbers, not the narrative you’d prefer to tell.
How Long Each Stage Actually Takes
Clients often ask how long this whole sequence should take before they’re allowed to decide. In practice, stage one — buying and using a tool hard enough to find its edges — needs at least two full quarters, and ideally closer to a year, especially for businesses with any seasonality in their workflow. Stage two, quantifying the workarounds, is faster than people expect once you commit to doing it; a focused week of interviews with the staff actually doing the workaround usually produces a defensible number. Stage three, checking the operational signs and evaluating whether a different vendor solves the problem, typically takes another month if you do it properly — real trials with real data take time to run honestly. All told, a business moving through this sequence in good faith is usually 12–18 months from "we’re frustrated" to a confident decision. That sounds slow next to the urgency most owners feel, but it’s considerably faster, and cheaper, than building the wrong thing and discovering it a year in.
The Sequence Doesn’t End at "Build"
If the sequence does land on building, that’s not the end of the discipline — it’s where a different kind of rigor starts, in the form of a proper discovery phase and specification before any code gets written. I cover what that discovery process should actually look like, and what a good specification includes, in Build vs Buy: When Custom Software Is Worth It. The sequencing logic in this piece is what gets you to a confident yes or no; the next piece is what makes sure a yes doesn’t turn into a wasted development budget.
Buy then build isn’t a slogan, it’s a sequence with checkpoints. Each checkpoint is there to stop you from committing to an expensive custom build when a cheaper fix was available, and to stop you from staying on an expensive packaged tool long after it’s stopped earning its keep.