Operating Notes
Build versus buy is really a question about who owns the interface
The standard version of build versus buy is a cost comparison: engineering time and maintenance burden on one side, license fees and integration work on the other. Run the numbers, take the cheaper path.
That framing is usually the wrong first question, because it assumes the two options produce the same thing at different prices. Often they don’t. They produce the same outcome through completely different interfaces, and the interface is what determines whether the capability is actually usable for what you’re trying to build next.
The capability isn’t the constraint. The interface is.
Checking whether a flight is within a travel policy’s fare cap is not hard. Ranking a list of itineraries by a traveler’s stated preferences is not hard. Both are the kind of logic a competent engineer writes in an afternoon. If the question is “can we build this,” the answer is almost always yes, and that makes the build-versus-buy comparison feel like it should favor buying — why write code for something a vendor has already solved, tested, and hardened over years of production use.
The question that actually matters is different: does the vendor’s version expose that logic as something you can call, compose, and put in front of an agent — or does it exist only inside their own interface, reachable by a human clicking through their product?
Most established corporate travel platforms have a policy engine. It works. It’s also generally locked inside their own booking flow, designed for a person filling out a form, not for a system that needs to call it programmatically, chain it with other tools, and hand the output somewhere else.
Why we built the policy layer instead of buying it
I built a small MCP server that searches Google Flights, labels every result against a policy file, and ranks the compliant ones by preference. The underlying logic — fare caps, cabin class rules, blocked carriers, nonstop and alliance preferences — is genuinely simple. What made it worth building rather than buying was narrower than the logic: it needed to be an interface an AI agent could call directly, with structured input and output, composable with whatever else the agent was doing, deliberately stopping short of completing a booking so a person stays in the loop on the transaction itself.
That’s the shape of a build decision worth making: not “we can build this cheaper,” but “the interface we need doesn’t exist in a form we can use, and building a thin layer that exposes exactly that interface is worth more than the underlying logic being simple.”
A rule that generalizes
Buy when the capability is undifferentiated and the vendor’s interface already fits how you need to use it — accounting, payroll, most infrastructure. The logic being complex or simple is beside the point; what matters is that the interface is already the one you need.
Build when the capability itself is simple but the only available version is trapped behind an interface designed for someone else’s workflow. In that case you’re not really building the capability. You’re building the interface, and the underlying logic is almost incidental.
The mistake in either direction comes from evaluating the wrong axis. Building because “we can do it cheaper” ignores that the vendor’s maintenance burden was never really the cost. Buying because “they’ve already solved this” ignores that solving the logic was never the hard part — getting it in a shape you can actually use was.