The build-versus-buy debate usually gets settled by whoever is most persuasive in the room. A technical founder leans toward building because building is the thing they know how to do. A finance-minded operator leans toward buying because the invoice is predictable. Neither instinct is a framework.
What follows is. Four tests, applied in order, that produce a defensible answer for a specific problem at a specific stage of your company. The answer changes as you grow, which is fine — what matters is that you can explain why you chose what you chose.
Test 1: Is this your differentiator?
Ask what your customers would notice if this system disappeared. If the honest answer is "nothing, as long as the work still gets done," you are looking at infrastructure, and infrastructure should be bought.
Payroll, accounting, email, calendars, document storage, standard CRM functions — none of these will win you a customer. Building them means spending your scarcest resource on a problem thousands of companies have already solved.
The opposite case is real but narrower than most founders assume. If the system encodes something specific about how you operate — a pricing model competitors cannot match, a fulfillment sequence that is genuinely yours, a data set nobody else has — then it may deserve to be built. The test is not "is it important?" Everything is important. The test is "is it ours?"
Test 2: Does off-the-shelf cover 80 percent?
Evaluate available products against the workflow you actually run, not the workflow you would design from scratch. If a product handles roughly four-fifths of it, buying is almost always correct — you adapt your process to the remaining fifth, or you accept a manual step.
Two traps live here.
The first is the demo gap: the demo covers your happy path and the product breaks on your exceptions. Insist on testing with your own messy data before signing anything, including the record that always causes trouble.
The second is the configuration cliff: a product that technically covers 80 percent but requires so much customization that you have effectively built software anyway, on someone else's platform, without owning the result. Heavy configuration carries the cost of building with none of the control.
Test 3: What is the integration burden?
Software rarely lives alone. Ask what has to talk to what, and in which direction.
- Does the product offer a documented API, or only file exports?
- Does data need to sync continuously, or is a nightly batch acceptable?
- Where does the system of record live for each piece of data, so two systems never both claim to be right?
- What happens to your workflow if the integration breaks for a day?
A cheaper product with no API can cost more than an expensive one that connects cleanly, because the difference gets paid every week in manual reconciliation. That reconciliation work is exactly what tends to end up as unbudgeted labor, and it is often the strongest argument for connecting systems properly rather than shopping for another tool.
Test 4: Who maintains it in year three?
This is the question that separates people who have shipped internal software from people who are about to.
Bought software has a maintenance model built in: the vendor patches it, and you pay for that. Custom software has a maintenance model too — you just have to name it. Who fixes it when a dependency breaks? Who updates it when a business rule changes? Who understands it after the original developer moves on?
If you build, the answers must exist before the first line of code: written documentation, a code repository you own, and a named person or partner responsible for upkeep. Ownership of code and data should be explicit in any agreement with an outside development partner. "We will figure it out later" has produced more abandoned internal tools than any technical failure.
The hybrid path most teams miss
Build versus buy is rarely binary. The common and underused middle option is to buy the platform and build the thin layer that is genuinely yours — a custom quoting calculator that writes into a standard CRM, a customer-facing portal that reads from bought back-office software, an internal dashboard that joins two systems you already pay for.
This gets you vendor-maintained infrastructure and proprietary logic where it matters. The maintenance surface stays small enough for a small team to own, which is the practical constraint most SMBs are actually managing.
The decision tool
Score each statement from 0 (strongly disagree) to 3 (strongly agree):
- Customers would notice if this system worked differently from a competitor's.
- No available product covers 80 percent of our workflow without heavy customization.
- The process it supports is stable and unlikely to change substantially within a year.
- We have or can retain the technical capacity to maintain it for at least three years.
- The data involved is ours and would be hard for a competitor to replicate.
- We can define "done" clearly enough to scope a first version.
14–18: Building is defensible. Scope a narrow first version and write the maintenance plan before you start. 8–13: Look hard at the hybrid path — buy the platform, build the differentiated layer. 0–7: Buy. Spend the saved time on adoption and process design, which will produce more value than the build would have.
One rule overrides the score: if you cannot write a plain-language description of what the software must do, you are not ready to build or buy. That description is the cheapest artifact in the whole project and the one most often skipped.
Frequently asked questions
Is building always more expensive?
Not always at the start, and often over time. Build cost is front-loaded and visible; buy cost is recurring and predictable. Compare them over the same multi-year window, and include maintenance labor on the build side or the comparison is meaningless.
What if we build and it does not work out?
Contain that risk with scope. A narrow first version that handles one workflow can be evaluated honestly and abandoned cheaply. Large first releases make abandonment feel like failure, so teams keep funding them past the point of sense.
Can AI tools change this calculation?
They lower the cost of producing code, which makes building look more attractive. They do not lower the cost of specifying requirements, integrating systems, or maintaining what you shipped — and that is where most of the real expense has always been.
How do we avoid vendor lock-in when we buy?
Check the export path before you sign. Confirm you can extract your data in a usable format, on your own schedule, without a support ticket. If you cannot, price the switching cost into the decision.