A build-vs-buy call that looked obvious, and was wrong

Composite, drawn from patterns across engagements, not one specific client.

A business I worked with needed a booking system. The obvious call looked obvious: buy one, dozens exist, why build. They bought one. Eight months later they were building a custom replacement anyway, at a higher cost than if they’d built from day one.

What the obvious call missed

The off-the-shelf tool handled bookings fine. It didn’t handle the business’s actual constraint: bookings needed to sync in real time with a separate inventory system that tracked physical resources, not just calendar slots. That requirement wasn’t visible during evaluation, because the sales demo never touched inventory, it only showed the booking flow looking clean.

Eight months of workarounds, manual reconciliation, and a part-time hire whose entire job became “keep the two systems from disagreeing” cost more than a custom build would have, and still didn’t fully solve it.

Where the evaluation actually failed

Not in comparing booking tools. In not asking, before evaluating any tool at all, what this system had to integrate with and how tightly. That question would have surfaced the inventory dependency immediately, and changed the entire decision before a dollar was spent.

What the eventual fix looked like

A custom booking layer, thin, built specifically to solve the inventory-sync problem, sitting in front of a much simpler off-the-shelf calendar underneath. Not fully custom, not fully bought, the actual constraint decided the shape.

The lesson, generalized

“Obvious” build-vs-buy calls are usually obvious because the hardest constraint hasn’t been named yet. The fix isn’t distrust every easy answer, it’s naming the one or two constraints that would actually break the easy answer, before committing budget to it.