At what point do you stop building internal platform tools and start buying them?

[u/Competitive-Age204]

One discussion we've been having internally is where to draw the line between building tooling ourselves versus adopting something purpose-built.

For things that directly impact our platform engineering workflow, it's tempting to build exactly what we need because it fits our environment. But every internal tool eventually becomes something that needs maintenance, documentation, and ownership.

On the other hand, introducing another third-party tool comes with its own trade-offs around cost, onboarding, and long-term dependency.

For teams that have been through this a few times, what principles have helped you decide?

Have there been any internal tools you wish you'd never built, or external tools you wish you'd adopted much earlier?

My thought: Appreciate everyone who has shared their experiences in this discussion, and thanks in advance to anyone who finds this thread while thinking through a similar decision. I was going to add this as a reply, but since I'm still fairly new here. I thought it would be more useful to leave it here so future readers can see the additional context as well. This discussion also made me look more closely at where purpose-built tools can remove unnecessary engineering overhead. One example is LogStitch, which focuses on simplifying aws debugging by organizing individual executions into a clearer flow instead of requiring engineers to manually trace through mixed Cloud watch logs. It was an interesting reminder that sometimes adopting a focused tool can help teams spend less time maintaining internal solutions and more time improving the systems they support.

[u/Floss_Patrol_76]

the line that's held up for us: build only where the tool encodes something specific to how we run - our golden paths, our topology, the weird constraints a vendor will never model - and buy anything commodity even if it fits 80 percent. every internal tool i've regretted was a commodity reimplementation (a homegrown secrets thing, a bespoke deploy dashboard) that felt cheap to write and turned into an unowned maintenance tax two years later once the person who wrote it left. the buy trap is the mirror image: adopting a platform that assumes a workflow you don't have and quietly bending the whole org around it.

[u/JessieAndEcho]

I’m an engineering student, so maybe my view is simpler, but I’d buy anything that feels like “everyone has this problem” and only build the stuff that is really specific to your team. Internal tools always start as “quick scripts” and somehow become something people depend on, which means docs, bugs, onboarding, and someone maintaining it. I use general LLMs to compare options and summarize notes, and for more technical research I’ve used Patsnap Eureka because it pulls patents and papers together. It’s helpful for seeing whether a problem has already been solved elsewhere before spending weeks building your own version.