Build vs. buy for internal ops tools: a decision framework from the field

A process that eats two hours of manual work every time it runs, needs three or four rounds of chasing people for responses, and costs roughly ninety dollars per use for an off-the-shelf tool — on paper, that looks like an easy build decision. It isn't, and the reason has nothing to do with technology.

Start with the real cost, not the sticker price

A DACH-region leadership-development firm ran a recurring 360-degree feedback process through an existing SaaS tool. The license itself cost around ninety dollars per use — cheap, on its face. What didn't show up on that invoice: someone manually entering every participant and every rater, roughly two hours per run. Reformatting rater lists into the exact four columns the tool expected. Then three or four rounds of reminder emails before everyone had actually responded. None of that was billed. All of it was the real cost.

The gap became visible the moment a new client asked for something slightly different: their own leadership-competency model and a matching set of survey questions inside the same tool. The license fee barely moved. The manual-labor cost did, sharply — a new competency model meant new categories, new scoring logic, new edge cases nobody had mapped yet. That's usually the exact moment the "let's just build it ourselves" conversation starts. It's also the wrong moment to start it, because nobody in that conversation is yet asking the question that actually matters.

Buy the substrate, own the differentiator

Build vs. buy is rarely a clean either/or. It's a spectrum, and the real lever isn't "build or buy" — it's who owns the front end: who controls the parts that make the offering distinct, and who runs the plumbing that every company doing this kind of work needs anyway (logins, hosting, data storage, uptime).

The useful framing is to buy the substrate and own the differentiator. The parts that look the same for every firm doing this kind of work — authentication, survey delivery, basic reporting — are worth renting, because someone else's team maintains them for you. The parts that are specific to how a firm actually works with its clients — the competency model, the routing logic, the exact shape of the report a client receives — are worth owning, because that's the actual value being sold.

The question that actually decides it

Feature comparisons and cost spreadsheets won't settle this. What settles it: who needs to be able to read and manage this data on their own, without going through whoever built it, three years from now? If the answer is "our own team and our clients, independently, for a long time," the case for owning more gets stronger — even against worse unit economics today. If the answer is "a handful of times a year, for a process that could plausibly look completely different next year," renting stays cheaper for a very long time.

Do the maintenance math, not just the build math

The initial build estimate matters less than people assume. In this case: building just the scoring and reporting layer took about a week. A full working replacement — intake, reminders, scoring, reporting — took roughly three to four weeks. Against a ninety-dollar-per-use bill running forever, that looks cheap. But the comparison only holds on day one.

Every request after that — a new competency model, a new question type, a different way to calculate an average when a manager's own score shouldn't count toward it — becomes a change request against something the firm now owns outright. What used to be the vendor's roadmap problem becomes the firm's backlog item.

A framework to reuse

Before the next build-vs-buy call, three questions tend to do more work than any feature matrix:

• Who has to be able to read and manage this independently in a few years — our team, or the client?
• Is the manual cost per run — hours, reminder loops, reformatting — actually shrinking as volume grows, or staying flat?
• If we build it, what part is genuinely our differentiator — and what part is just plumbing we'd be building for the sake of owning it?

None of this makes the decision automatically. What it does is stop the conversation from circling a feature list and put it back on the question that was the real one from the start.