Should we buy software or build our own?
Buy anything where the process is a commodity and the vendor's opinion is better than yours: accounting, payroll, dispatch, email. Build where the process is how you actually win, or where the value sits in the join between systems that no vendor sells. For most service businesses the right answer is both — buy the systems of record, build the thin layer that connects and interprets them.
The question is almost never all-or-nothing
Framing it as build versus buy usually produces a bad decision, because it forces one answer onto a stack that needs several. A service business running field operations, a phone system, ad accounts and a website already owns four or five bought products. The real decision is which layer you build.
The layer worth building is rarely a replacement for any of those. It is the part where they meet: the place where a call, a booking, an ad click and an invoice become one story. No vendor sells that, because it is specific to which products you happen to own.
A test that actually decides it
Ask whether the process is a source of advantage or a cost of doing business. If a competitor could buy the same tool and run the same way with no disadvantage, buy it. If the way you do it is a reason customers choose you, or the reason your margins hold, do not hand it to a vendor who sells the identical product to everyone in your market.
- Buy when the process is regulated, standardized, or well understood — accounting, payroll, tax, payments. The vendor's constraints are a feature.
- Buy when the product's real value is its network or data — maps, ad platforms, review sites.
- Build when the requirement is a join across systems you already own.
- Build when the process encodes a decision that is yours: how you rank leads, how you rate a call, how you route a job.
- Build small when the alternative is a person doing manual translation every day.
The hidden costs on each side
Buying is not free of engineering. You inherit configuration work, integration work, data extraction limits, and the vendor's roadmap — which means a feature you depend on can change or disappear on someone else's schedule. You also inherit their idea of what your business is.
Building is not free of vendors either. Anything you build sits on top of libraries, cloud services and third-party APIs, so it needs maintenance whether or not you change it. The honest comparison is not cost versus zero; it is which set of dependencies you would rather manage.
The pattern that works for most operators
Keep the system of record bought. Keep the connective and interpretive layer yours. That layer is where reporting, alerting and automation live, and it is small compared to a full application because it does not have to reimplement scheduling, invoicing or payroll.
This is also why a modular platform plus targeted customization tends to beat both extremes: the common parts are already built, and the part that is specific to your business gets built rather than approximated. If the platform covers most of the problem, the remaining work is narrow enough to scope honestly — see custom AI development for how that split usually falls.
Topics: build vs buy · strategy · systems of record · integration
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.