Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Internal Platforms to Kill the Build vs Buy Trap
Transcript
- Lucas: So you're a CTO and your product team comes to you and says we need a document generation service. Do you buy a vendor tool or do you have your team build it from scratch? Luna: Classic build-versus-buy. And most of the time the answer is 'it depends' which doesn't help anyone. Lucas: Exactly. But there is a third path that I think is underused. I came across a really clean case from a mid-stage fintech company — about 80 engineers. Their CTO, I'll call her Sarah, faced exactly this question three times in six months. First it was document generation, then a notification engine, then a data export tool. Luna: Three different teams asking for three different things. I can see where this is going. Lucas: Right. Instead of making three separate build-versus-buy decisions, she asked a different question: what do these needs have in common? She realized all three were essentially CRUD services with some business logic. So she created a small platform team — three engineers — and told them to build an internal platform that any team could use to spin up those CRUD services quickly. Luna: So she went build — but not for each individual need. She built a reusable foundation. Lucas: Exactly. The platform team spent about six weeks building a boilerplate service with common patterns: authentication, logging, a basic API layer, database migrations, and a simple deployment pipeline. Then they exposed it as an internal tool with documentation and a CLI. Any team could type a command and get a new service scaffolded in under a minute. Luna: And what happened when the product teams actually used it? Lucas: She tracked two metrics: cycle time from request to production, and developer NPS. Before the platform, the average cycle time for a new service was about four weeks. After, it was under two weeks — a 40 percent reduction. Developer NPS went from 25 to 55. The teams felt like they owned their own destiny. Luna: Forty percent reduction is huge. But I'd push back — doesn't this require a certain scale? If you're a 12-person startup, a three-person platform team is a quarter of your engineering headcount. Luna: And at that size, the trade-off might not be worth it. Lucas: You're right. Sarah's company had 80 engineers, so three people was less than 4 percent of headcount. For a smaller team, the math is different. But I think the principle scales down if you're smart about it. A two-person startup could just build a shared library or a set of templates, not a full platform team. Luna: So it's about abstracting common patterns, not necessarily having a dedicated team. Lucas: Exactly. The key insight is that Sarah didn't start by building a platform. She started by asking three product teams what was slowing them down. The platform was the answer, not the assumption. That's the opposite of what I see at a lot of companies. Luna: Yeah, I've seen the opposite too. A legacy enterprise I consulted for built a massive internal platform — it took two years and a dozen engineers — and then nobody used it because it didn't match how product teams actually worked. Lucas: That's exactly the failure mode. Sarah avoided that by starting small. Her first platform only supported three types of services. She built it iteratively, adding capabilities only when multiple teams asked for them. She didn't try to build the perfect platform upfront. Luna: So the lean startup approach applies to internal tools too. Build a minimum viable platform, get feedback, iterate. Lucas: Yes. And she also set a clear policy: if your team needs a new capability, you contribute back to the platform. That prevented the platform team from becoming a bottleneck. Luna: So the platform team is more of an enabler than a service desk. I like that. Lucas: Right. They maintain the core, but product teams extend it. That also solved a cultural problem. Developers felt ownership over the platform because they helped shape it. Adoption was high because the platform was built by their peers, not by a separate team in a silo. Luna: Let's talk about the financial side. How did she justify the three-person investment to the board? Lucas: She framed it as a cost-avoidance play. She showed that over six months, the three product teams would have spent a combined 30 engineer-weeks on building and maintaining three separate services. The platform team spent 18 engineer-weeks building the platform, and then each new service took maybe one engineer-week instead of ten. The board signed off because the numbers were clear. Luna: That's a concrete ROI calculation. I bet a lot of CTOs struggle to make that case. Lucas: They do. But Sarah had a simple rule: if two or more teams independently need the same capability within a quarter, it's worth considering a shared solution. That rule gave her a decision framework that didn't rely on gut feel. Luna: And what about the classic build-versus-buy question? Did she ever buy a vendor tool after the platform was built? Luna: So the platform actually made the buy decision clearer. If the need fits the platform pattern, build internally. If it's a complex domain where you don't want to build expertise, buy. Lucas: Exactly. And that's the real value. Instead of debating each decision in isolation, you have a framework. The platform becomes a forcing function for consistency. Over time, the team got faster at making those decisions. Luna: I want to zoom out for a second. How do you know if your org is ready for this approach? Lucas: Good question. I'd look for three signals. One: you're seeing the same request from multiple teams. Two: your cycle time for building new services is measured in weeks, not days. Three: your developers are complaining about boilerplate and repetitive work. If you have all three, you're a candidate. Luna: And if you're the CTO, how do you start without over-investing? Lucas: Start with a single service. Pick the most painful, most repetitive one. Spend two weeks building a shared version. Then let one team dogfood it for a month. If it works, expand. If not, you've only lost two weeks. Luna: That's a low-risk experiment. And if it fails, you can still buy the vendor tool. Lucas: Right. The build-versus-buy decision isn't binary anymore. You can build a little, test, and only commit to a bigger build if the experiment works. Luna: I think a lot of engineering leaders will find this useful. It's a practical way to break out of the analysis paralysis. Lucas: If today's conversation gave you something usable, that's exactly why we do this. And speaking of keeping this going — a handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds making this many episodes ad-free. No pressure, just a fact. Luna: Yeah, it's a small community that makes it possible. And we're grateful. Lucas: So back to Sarah's case. Six months after the platform launched, she measured something she didn't expect: the number of production incidents dropped by 25 percent. Because the platform enforced consistent logging and error handling, teams were catching issues earlier. Luna: That's a nice side effect. So the platform improved reliability almost as a byproduct. Lucas: Exactly. And that's the kind of compounding value that makes the internal platform case so compelling. It's not just about speed. It's about quality, consistency, and developer happiness. Luna: Are there any other examples you've seen work well? Lucas: There's a well-known one from Spotify, where they built a platform called 'Squad Health Check' — though that was more about process than technology. And Netflix's internal platform for chaos engineering is another. But I think Sarah's story is more relatable for mid-size companies that don't have Netflix's resources. Luna: I think that's the takeaway. You don't need to be a tech giant to benefit from this pattern. You just need a clear signal and a small experiment. Lucas: Yeah. And the willingness to say 'we'll build this shared piece, but only if multiple teams need it.' That's the discipline that makes it work.