A transportation and logistics company, building out a platform for their operations team. From day one the ops team pushed back, out of fear.
What happens if we leave our vendor? What if we miss something?
Fair questions. They had built their entire operation around that software over five years.
The moment it turned
Halfway through a design meeting I mentioned something in passing. We had built a tool for a law firm where paralegals could send clients a link requesting missing information. Later we evolved it so the AI would detect on its own that information was needed and send the request through a secured magic link.
The operations manager's eyes lit up.
"Could we have that? As a 3PL we constantly need information from smaller carriers, and our people have to chase it down."
Yes. About forty hours to build and deliver.
At the demo he laughed and said their current vendor could never have done that, and never that fast.
The feature is not the point. What matters is what he realised in that moment, and it reframes the whole question.
Build versus buy is not a cost question.
It is a question about who owns your roadmap.
What five years of stability was actually buying
Here is the part that takes a second to sit with.
Nothing had gone wrong. The vendor had not failed them. There was no outage, no price gouge, no support disaster. By every metric the ops team was tracking, the relationship was healthy.
What looked like comfort was not safety. They were quietly losing the innovation game, one feature request at a time, on somebody else's schedule.
That is the reason fear was the wrong instrument here. Fear measures what could go wrong with the vendor. It does not measure what never happens because of the vendor, right? Five years of nothing going wrong is indistinguishable from five years of nothing happening, and only one of those shows up in a status report.
So when you weigh build against buy, price in something most analyses omit entirely: the cost of innovating slower than your competitors.
The harder version of the same story
There is a worse place on this spectrum, and I ran into it on another engagement this year.
A product team whose entire platform sits on top of a vendor's system. That vendor declined to provide an API. No SLA either.
So there is no integration path, no automation path, and no measurable commitment about whether the thing will be up. They work at risk, permanently, with no credible exit and no leverage in any conversation about price or roadmap.
The logistics team had a slow roadmap. This team has no roadmap access at all. Same axis, further along it.
And notice what that experience did to them. Every other dependency they have built since is designed for exit, because they have already paid for that mistake once and will not pay for it twice. The scar tissue turned into architecture.
Now the correction, because "build it yourself" is the wrong takeaway
I watch businesses get this decision wrong constantly in the other direction. Three questions before you build anything.
1. Is the problem so specific to your business that no existing tool can handle it?
Not 10% better. A core workflow that off-the-shelf software misunderstands. If a tool gets you 80% of the way there, you should almost always buy it.
2. Will building this create a real, durable moat?
If a competitor can buy a similar tool tomorrow and get the same result, your custom build is not a moat. It's an expensive project that protects nothing.
3. What is the true opportunity cost?
Every hour and dollar spent building is one not spent on sales, marketing, and talking to customers. Could you reach the market faster by buying something imperfect now?
The rule that falls out: buy to solve generic problems, build only your own unique magic.
I have argued the opposite side of this hard enough to kill a half-million-dollar engagement I was hired for, so treat these two pieces as a pair. The gap analysis question protects you from building what already exists. This one protects you from the slower, quieter failure of never building the thing only you could.
What owning the roadmap costs you
That story has a happy ending. Building still has a bill, and it is worth naming before you decide.
You own the pager. A vendor's slow roadmap is annoying. Their on-call rotation is free. Build it yourself and every 2am failure during your busiest week is your phone.
Compliance moves onto your books. Certifications, pen tests, the security questionnaires your own customers send you. That used to be a logo on somebody else's marketing page.
Key-person risk is quiet. Forty hours to build, then years of the one person who understands it. Vendors have turnover too, but their software survives it.
Forty hours is the build, not the lifetime. That number is real and it is also the smallest number in the whole story. Nobody quotes you the maintenance, and the maintenance is where custom software actually costs money.
The gap analysis costs weeks before anything ships. Scale it to the size of the bet. On a two-week internal tool it is pure overhead.
When buying is the right answer. The workflow is generic, the vendor is competent, and nothing about it distinguishes you from a competitor. Then a roadmap you do not control costs you nothing, because you were never going to move that surface anyway.
The question to ask about your most critical vendor
Not "are they good." They probably are.
Ask: when you request a feature, when do you get it, and who decides?
If the honest answer is that you file it and hope, you do not have a vendor relationship. You have a roadmap owned by somebody whose priorities are not yours.
That may still be the right trade. It usually is, for the generic 80%. Just make sure the surface where you are supposed to be different is not on the list.
The short version. Build vs Buy Is Really About Who Owns Your Roadmap, told the day after the demo.
Everything above stands on its own.
Chris