About This Newsletter
Build internal tools once.
Unblock every backend team, forever.
A newsletter for Staff Engineers, Senior Backend Engineers, and engineering leaders who build (or fund) the internal platform tools that entire engineering organisations depend on.
The Problem
It was a Tuesday morning sprint planning when someone said, “Which team owns the HTTP client library?” Three people answered at the same time. Three different answers. That was the moment we realised we had multiple versions of the same library running in production, none of them compatible, none of them anyone’s official responsibility.
That’s not a rare war story. That’s most engineering orgs past 50 engineers, described accurately.
Here’s the situation I’m guessing you recognise. Your backend teams are smart. They ship fast. But every time a new service gets started, someone writes another HTTP client wrapper from scratch because they don’t trust the last team’s version. Your Kafka consumers have four different retry strategies across the codebase. Nobody knows which one is correct. Your onboarding document tells new engineers to “check the wiki”, and the wiki hasn’t been touched in 8 months. Your Staff Engineers spend roughly 20% of their time on work that should have been a shared library two years ago.
And when something breaks at 2 am, the first 45 minutes are just figuring out which implementation is actually running.
“The cost of not having a platform team doesn’t disappear. It gets paid in Senior Engineer hours, one reinvented SDK at a time.”
Now imagine the alternative. A new service gets scaffolded in 10 minutes with all the defaults already right: structured logging, trace propagation, circuit breakers configured sensibly, a Kafka client that handles retries and dead letters without the engineer having to think about it. A new engineer joins and is shipping to production in two weeks, not one month. Your Staff Engineers are working on hard problems, not copy-paste reviews. When something breaks, the shared library is the first place everyone looks, because there’s only one implementation to debug.
That’s not a FAANG dream. That’s what a well-built backend platform actually buys you. And almost nobody writes about how to get there.
Every issue starts with something real. A decision I had to make, a thing that broke, a call I got wrong the first time. What we found after three failed SDK designs changed how I think about internal library adoption entirely. I’ll share that in this newsletter.
Who Is This For
There are three types of people who tend to find this useful.
Senior Backend Engineers who’ve noticed the same problem being solved badly across three different teams and feel the itch to fix it permanently.
Staff Engineers who have quietly realised their highest-leverage work stopped being in their own pull requests some time ago.
Engineering leaders (EMs, VPs, CTOs) who’ve watched their team double in size without a proportional increase in velocity, and suspect the answer isn’t another 10 engineers.
If that last one resonates, you don’t need to follow the code to get value here. What this newsletter gives you is the vocabulary to have more precise conversations with your platform team, a way to recognise when a platform investment is producing real leverage versus when it’s producing maintenance debt, and a clearer picture of what the shared layer in your org should actually look like at your stage of growth.
This Is Probably For You If:
You’re a Staff Engineer or Senior Backend Engineer who builds or wants to build internal SDKs, shared frameworks, or platform services that product teams depend on. And you want to do it properly, not just quickly.
You’re an Engineering Manager who gets a platform team update every two weeks and still isn’t sure if what they’re building is the highest-leverage thing they could be working on.
You’re a VP of Engineering or CTO who’s hired good engineers, but velocity hasn’t scaled with headcount, and you think the shared infrastructure layer might be where the drag is hiding.
You’ve inherited a codebase where six services each have a different HTTP client implementation, nobody agrees on the error response format, and every new service starts from a slightly wrong copy of the last one.
You’re aiming for a Staff-level role, and you’ve started to suspect that building internal tooling that other engineers depend on is the fastest path to the impact that promotion requires.
Probably Not For You If:
You want beginner tutorials on microservices, API design, or system design interview prep.
You’re looking for DevOps, SRE, or infrastructure platform content. That’s a real discipline, it’s just a different one.
A Note For Engineering Leaders
Most platform engineering content is written by engineers for engineers. Leadership gets ignored. That’s a problem, because the decision to invest properly in a backend platform almost always sits with a leader, made with incomplete information about what a good platform team actually produces versus what a struggling one produces.
The leaders who read this tell me the same thing: they finally had language for the problem they’d been watching for months. That matters more than it sounds. If you can’t name what’s broken, you can’t fix it in a headcount conversation or a quarterly planning cycle.
What Engineering Leaders Get From Reading This:
A way to tell if your platform team is building leverage or busywork. A platform team shipping shared SDK libraries and internal tooling that cuts every product team’s development time is one thing. A platform team that has quietly become a ticket queue for things nobody else wants to own is a different thing. From the outside, they can look identical. After reading a few issues, they won’t.
Shared vocabulary with your platform lead. The roadmap decisions, intake frameworks, and charter questions that come up here are what your platform lead is thinking about in their 1:1s. Reading the same content closes the gap between what they’re trying to explain and what you’re trying to decide.
A diagnosis for why velocity isn’t scaling with headcount. When your teams are shipping frequently, but features still feel slow, the bottleneck is usually in the shared layer. The places every team touches but nobody officially maintains. This newsletter names those bottlenecks with enough specificity to act on them.
The end state, described clearly enough to aim for. What does it actually look like when the backend platform is working? New services are scaffolded in minutes. New engineers ship in days. Your Staff Engineers are solving hard problems, not reviewing the same patterns for the sixth time. Platform work is invisible because nothing is broken. That’s the goal. Backend Platform shows you what it takes to get there.
