Somewhere in the next quarter your business will need a capability it does not have yet. Someone will gather vendor quotes, someone else will estimate what the same thing would take to build internally, and the meeting will become a debate about those two numbers. The debate is usually well informed, and it usually opens far too early.
Build versus buy is a real decision that eventually needs an answer. Asked first, it produces a comparison between two construction estimates, and construction is rarely where these projects succeed or fail. Four questions asked ahead of it will tell you considerably more, and they often make the build-versus-buy answer obvious by the time you arrive at it.
What capability are we trying to create?
Requests tend to arrive named after products. Someone asks for a CRM, a business intelligence tool, or a scheduling system, and the shape of the answer is settled before anybody has described the underlying need.
Restating the request as a capability reopens the field. “We need a CRM” becomes “we need to know which accounts are drifting away from us, early enough that somebody can pick up the phone.” The first sentence points at a product category. The second points at a problem with several possible answers, one of which might be a weekly report already sitting in a system you own.
A capability statement also outlives whichever vendor you choose. Products get acquired, repriced, or discontinued, while the capability you needed stays roughly constant for a decade. Writing it in plain language, before any product name enters the room, gives you a fixed thing to measure every later option against. We covered an adjacent failure in the two-year answer to a two-week problem, where the response outgrew the problem it was bought to solve.
Is it differentiating?
Every business runs two kinds of capability. The first kind is why customers choose you, including the way you underwrite, the way you route a job, or the service promise your competitors have failed to match. The second kind keeps the lights on, and payroll works out to be the same problem for you as for everyone else in your industry.
Buy the second kind on the best terms available, with the least customization you can tolerate. Effort spent bending a general tool around your particular payroll process is effort taken directly from the work that sets you apart.
The first kind deserves more thought, and it is usually smaller than people expect. In a mid-market business the differentiator is often a process somebody invented years ago and never wrote down, which is exactly what a configured off-the-shelf product tends to flatten.
A regional bank we worked with showed the distinction clearly. Underwriters were spending a substantial part of each week on application intake rather than on credit decisions, which is the one capability a lender competes on. Automating the intake and the operational reporting around it compressed a twenty-hour weekly reporting cycle into ten minutes and returned that capacity to the judgment only underwriters can apply.
What will it cost to operate for three years?
The purchase price and the build estimate are the two smallest numbers in this decision, and they attract most of the attention in the room.
On the buy side, a three-year figure includes seat growth as you hire, the implementation partner, the uplift at renewal, the administrator time nobody budgeted for, and the upgrade that breaks an integration you had forgotten about. On the build side it includes hosting, monitoring, dependency updates, and the cost of whoever maintains the thing once the person who wrote it has moved on.
Three years is the right window for a smaller business, because it is long enough to contain one renewal cycle and at least one staffing change, which is where the quiet costs surface. Our paper on data infrastructure pitfalls in community banking works through a version of this, where the binding constraints turned out to be budget, staffing, and vendor dependence rather than technology.
What is the integration and change-management burden?
This is where mid-market projects most often fail, and it appears on neither estimate.
Integration is the unglamorous half. Data has to arrive from the systems you already run, in a shape the new capability can use, on a schedule somebody owns. A business running a dozen applications that were each chosen well on their own terms can discover that connecting two of them costs more than either one. We worked with a nationwide services business running 35 disconnected systems, where consolidation cut reporting labor by 70% and returned around $12M a year.
Change management is the half that decides whether any of it matters. A capability that works technically and goes unused is a total loss, and the usual cause is a manager who kept the old spreadsheet because nobody explained what had replaced it. Budget for training, for a period of running both ways, and for the authority to retire the old process once the new one holds.
Where this leaves you
Four questions, asked before the build-versus-buy debate opens. What capability you are creating, stated without naming a product. Whether it differentiates you or simply keeps you running. What three years of operation costs on either path. What it will take to integrate the result and move people onto it.
Answer those four and the build-versus-buy question tends to answer itself. A commodity capability with a heavy integration burden points firmly one way, and a differentiating process with modest operating cost points the other. Once in a while the four answers reveal that the right move this year is neither, and that the capability is worth less than the disruption of acquiring it.
Vendors will keep getting better at selling to businesses your size, and the pace of that is increasing. The businesses that spend well over the next few years will be the ones that built a habit of asking these four questions before the demos start.
If your team is walking into one of these decisions, the shortest path is usually somebody senior who has made the call several times and holds no stake in the answer. That is the case for fractional leadership in a single sentence.