Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses In-House Tooling to Solve the Build vs Buy Trap
Transcript
- Lucas: Last month I was talking to a CTO at a fifty-person B2B SaaS company, and she told me something that stopped me cold. She said her team spent roughly forty percent of their engineering budget on third-party tools — and still, developers were complaining that the tools didn't fit their workflows. Luna: Forty percent? That's massive. And if they're still unhappy, something's broken in the build-versus-buy decision. Lucas: Exactly. And I think that's the episode we need to have today. Not the classic 'build everything' versus 'buy everything' debate — but the messy middle. The stuff that's too niche for a vendor to get right but too critical to leave half-baked. Luna: So we're talking about internal tooling decisions. When it makes sense to build a small thing in-house versus buying a heavy platform. Lucas: Right. And I want to anchor this in a specific case. That CTO I mentioned — let's call her Sarah — runs a company that does compliance automation. Think audit trails, access control logs, that kind of thing. She had a choice: buy a deployment orchestration tool that cost sixty thousand dollars a year, or have two engineers spend about three months building a minimal internal system. Luna: And she built it. Did it work out? Lucas: It did. But not because the internal tool was better. It was actually uglier, had fewer features, and the first release was buggy. The win was integration speed. The third-party tool would have required her team to adapt their entire CI/CD pipeline to match the vendor's API. The internal tool was built to mirror exactly how her team already worked. Luna: So the real cost of buying wasn't just the license — it was the process change. I bet a lot of teams underestimate that. Lucas: Hugely. Sarah's team tracked the time. After the internal tool was stable, they saved about two hundred engineer-hours per quarter compared to what they would have spent integrating and maintaining the vendor solution. And those hours went back into their core product. Luna: Two hundred hours a quarter — that's almost a full-time engineer. So the build paid for itself in a few quarters. Lucas: Exactly. And that's the kind of math that rarely makes it into a vendor's ROI calculator. But I want to be careful here — I'm not advocating build-everything. The trap is the opposite. Teams that pride themselves on being 'makers' often build stuff they shouldn't. Luna: Right. Like authentication. Or logging. Or any commodity service where a vendor has thousands of customers ironing out edge cases for you. Lucas: Exactly. So where's the line? I've been thinking about a simple rubric. You should build when the tool is a core differentiator for your product or when the integration cost of buying exceeds the build cost within your planning horizon. You should buy when the tool is a commodity and the vendor's standard integration path works for your team. Luna: And there's a third option, right? Open source with some customization. Lucas: That's actually the sweet spot for a lot of teams. Take something like a workflow engine. You can pull an open-source project, wrap it with your own configuration layer, and get eighty percent of the value of a commercial product for a fraction of the cost. But you need the in-house expertise to maintain it. Luna: And that's where the cultural challenge comes in. Some engineering teams don't want to own infrastructure. They want to treat everything as a service call. Lucas: Right. Sarah's team had the opposite culture — they were fine owning their deployment pipeline because they saw it as core to their developer experience. But I've worked with teams where the developers would revolt if you asked them to maintain an internal tool. Luna: So the build-versus-buy decision is also a people decision. You have to know your team's appetite for maintenance. Lucas: Exactly. And that's why I think the best approach is a hybrid. You buy the commodity stuff, you build the differentiators, and for the middle tier you adopt open-source and contribute back if you can. The key is to have a clear process for deciding which bucket something falls into. Luna: And you update that process as your team grows. What made sense at ten engineers is probably wrong at fifty. Lucas: For sure. And speaking of growth — you know, something that helps us keep these conversations going without any ads or sponsors is listener support. If today's tech conversation gave you something usable, like that rubric we just sketched out, and if you want to help us stay independent, you can support the show at buy me a coffee dot com slash fexingo. It's a small gesture that goes a long way to keep this ad-free. Luna: Yeah, it really does help. And we appreciate every bit of it. Lucas: Okay, back to the decision framework. Let's talk about a concrete example of where buying is the clear winner. Take monitoring and observability. That is a solved problem from a vendor perspective. Datadog, New Relic, Grafana — they've spent millions on UX and data processing. Building your own monitoring stack from scratch is almost never a good use of engineering time. Luna: Unless you're at a scale where the vendor bill is astronomical. I know some companies that built their own because they were spending seven figures a year on Datadog. Lucas: That's the exception. At that scale, the economics flip. But for most teams under, say, a hundred engineers, buying is smarter. The hidden cost of building is not just the initial development — it's the ongoing maintenance, the on-call rotations for the internal tool, the documentation you have to write. Luna: And the opportunity cost. Every hour spent on internal tooling is an hour not spent on your product. Lucas: Exactly. That's why I think Sarah's decision was so smart. Her team's core competency is compliance automation — not deployment orchestration. But because the vendor integrations would have forced a rewrite of their core workflows, the build made sense. The tool they built was tiny — a few thousand lines of Python and some YAML configuration. Luna: So it wasn't a huge investment. And they could afford to maintain it because it was simple. Lucas: Right. And that's another lesson: if you're going to build, keep it small. Don't try to replicate every feature of the commercial product. Build the minimum that makes your developers productive. Luna: I've seen teams fall into the trap of building a 'better' version of a vendor tool. They end up with a decade of technical debt. Lucas: Yes. The classic 'not invented here' syndrome. The healthy approach is to treat internal tools as a necessary cost, not a strategic asset. If you ever find yourself proud of how elegant your internal deployment system is, you've probably over-invested. Luna: That's a good rule. So what's the final takeaway for a CTO listening right now? Lucas: I'd say three things. First, do the math including integration costs and process change. Second, know your team's culture — will they own an internal tool? Third, use the rubric: build differentiators, buy commodities, adopt open source for the middle. And revisit the decision every year as your company scales. Luna: And don't build to be proud. Build to get out of the way. Lucas: Exactly. That's the line. Thanks for listening, everyone. We'll be back next week.