# What You're Actually Buying When You Buy a Company > When you need a capability you don't have, you can build it or buy a company that already has it. Buying looks faster. But you're not buying the demo;... Published: 2022-06-21 · Updated: 2026-06-23 · Topics: Digital Transformation, Product Strategy & Development, Engineering & Development · Author: Alan Wizemann When a company needs a capability it doesn't have, which in our case was the technology to offer dental care remotely, there are really only two doors in front of you. You build it, slowly, from scratch, and you live with how long that takes. Or you buy a company that already has the thing and you skip ahead. Buying looks faster, and quite often it genuinely is. But it comes with a trap that's easy to walk straight into when you're excited about the shortcut, which is that you are not buying the demo – you're buying the codebase, the deployment culture, and a thousand small decisions you didn't make and now have to live inside for years. I've sat on the evaluating side of this, doing the technical due diligence on an acquisition that would have handed us a capability we wanted quickly. And the one thing I'd tell anyone doing the same work is that diligence is not about confirming the deal. It's about discovering the risk, and those are very different jobs. If you walk in looking for reasons to feel good you'll find them, every time, because the company is selling and the product works in the demo, so the actual job is the opposite one: to find, as fast and as honestly as you can, everything that's going to become your problem on day one. So what are you actually evaluating once you're in there? Start with the code itself, because if the deal closes your engineers have to live in it. The question is whether it's built in a way your teams can really work with, or whether it's a foreign world they'll fight for a year. In our particular look the overlap was genuinely good – it would have been easy for our people to jump into their codebase. That matters more than almost any feature, because feature gaps you can close over time, and a codebase your team can't work in is a thing you're simply stuck with. Then look at how they ship, because deployment culture is destiny, and I don't say that lightly. A team that releases slowly, with long manual cycles between writing code and getting it live, is quietly telling you how fast you'll be able to move after the acquisition, which is to say not very, at least until you change it. You can teach a team a great deal, but velocity is cultural and it takes a long time to shift. A slow deployment loop isn't a detail you note and move past; it's a forecast of how the combined company will actually behave. Then comes the part that people skip because it's boring, and it's the part that actually matters most in a regulated space, which is the plumbing. When you're buying into healthcare, the value isn't the pretty front end at all. It's whether the unglamorous integrations exist and actually work – the way prescriptions get handled, the way insurance eligibility gets checked, the way payments flow, the way data moves between systems that were never once designed to talk to each other. Some of those integrations turn out to be modern and clean. Others are the kind of held-together-with-tape arrangements that work right up until the moment they're yours. You are buying every single one of them, and you need to know which is which before you sign rather than after, because afterward they aren't findings, they're emergencies. And then there's the part where you watch for the quiet red flags, the things that look fine or even clever in a pitch and worry you the moment you understand what you're really looking at. The one that stuck with me in our review was a payment model structured in a clever-sounding way that, the longer I sat with it, seemed like it might not actually be sustainable (the kind of structure that's elegant on a whiteboard and fragile in the real world), and nobody flags that kind of thing for you. It's not in the deck. You only find it by asking the unglamorous follow-up questions – who actually processes this, what legal entities exist to do it properly, what happens when the volume scales – and then noticing when the answers start to get vague, because the vague answer is itself the finding. Diligence is mostly the discipline of refusing to let a vague answer slide just because you've already decided, somewhere in the back of your head, that you like the deal. Here's the reframe that I think matters most about the whole build-versus-buy question: buying doesn't remove the work, it just changes it. The fantasy is that an acquisition lets you skip the hard part entirely. The reality is that you trade the work of building for the work of inheriting and integrating, and inheriting can honestly be harder, because you're absorbing decisions you didn't make, a culture that isn't yours, and technical debt you didn't create and now own outright. Sometimes that trade is absolutely worth it – speed and an existing, working capability are real and valuable things – but you have to go in clear-eyed that you are choosing a different kind of work, not avoiding work altogether. The honest test I'd put on any build-versus-buy decision is this one: imagine the deal closed yesterday and all of it is now yours, the code, the deploy process, the integrations, the payment model, the team's habits, every bit of it. Are you excited, or are you anxious? If the diligence has done its job you can actually answer that question, because you've seen past the demo to the thing you'd genuinely own, and if you can't answer it then you haven't done diligence at all, you've just watched a sales pitch with a lawyer in the room. So buy when buying genuinely gets you a working capability and a team you can build on faster than you could do it yourself. Just never confuse the speed of the shortcut with the absence of the work, because in the end you're not buying what the product does in the demo. You're buying everything underneath it that the demo was carefully arranged to keep you from looking at. --- Canonical: https://alanwizemann.com/articles/what-youre-actually-buying-when-you-buy-a-company