Do you really need an internal developer platform, and what are the trade-offs?

Quick answer: an internal developer platform (IDP) is worth building once the organisation is large enough that self-service (a developer requests a new service and gets a fully provisioned, tested, deployable environment without waiting on another team) pays back the significant upfront build cost — often 12–18 months of dedicated effort. For a team of two or three developers, that overhead usually isn't justified; solid CI/CD pipelines and guardrails deliver most of the benefit without the full platform investment.

Hi, a warm welcome to you, I'm Neil Millard, the DevOps and IT expert, and I also talk about contracting and stuff. Today we're talking about internal developer platforms, because developing code presents you with choices, and deploying is hard — choices are hard, and we just want to help each other out. Before that, I'd just like to mention tech-answers.club, where you can join me every Wednesday for a Q&A to ask all of your tech questions — deployments, DevOps, Kubernetes, containers, all that fun.

What is an internal developer platform?

It's essentially a customized self-service infrastructure and workflow ecosystem that standardizes and simplifies software development processes. Developers have a lot of choices when they develop code, so if we've got deep DevOps expertise already on hand, we can answer a lot of the questions common developers will have at that organization — what programming language should I use, or how are things deployed around here. It also provides a standardized CI/CD approach, with pipelines doing most of the hard work for you, plus automated testing, build, and self-service release. There's also a central hub for documentation, templates, and knowledge, with some built-in security and compliance guardrails, and on the back end, no DevOps setup would be complete without observability and monitoring.

Why might you need one?

It solves developer cognitive load — a lot of the decisions are made for the developer, so they can just get on with developing code without worrying about everything else that goes along with it. Here's a template application that just says "hello world" — it's written in a language the organization has agreed to support, using specific libraries to get you going fast. You pick up your ticket from whatever ticketing system you're using, download the template, and make your first build, then write some tests. Your first build is there, ready to go, and you can iterate on it from there based on whatever the ticket says. With those choices of language, frameworks, and dependencies all sorted, it just leaves the development bit, and with the pipelines in place and automated testing, those are covered for you too.

The benefit of having these things standardized is that it's easier to support, because everyone's trodden the same path before — you'll know the issues they're going to hit, you'll know how to solve them, and there'll be shared documentation they can access without bothering us, the DevOps people, or anybody else except maybe their team, who can say "have you seen this before? No, but have a look at the docs, there's the answer for you." So it speeds up learning for new starters and speeds up development, because there's lots of support already there — if all the developers were doing their own thing, they'd be hitting the same issues and brick walls over and over again, but for different languages and different frameworks. By building some guardrails in, you keep everyone on the same path, so everyone gets supported equally and strongly from day one, and it reduces toil and manual work.

As part of my operability, DevOps, and SRE role, I want to present a situation where everything is self-service. The developer says "I want to start a new project" — the documentation says "here's a template, off you get." The developer says "I want to deploy it" — the documentation says "go to this URL on our portal, click this button, feed in some information, and it will deploy it for you." Well, I've not built it yet — the answer is the same: look at the documentation on the portal, there's a pipeline that will build and test it for you. All of that extra cognitive load is taken away, and it makes everything and everybody a little bit happier.

The catch

This sounds absolutely amazing to the developer, but there's a catch — an IDP might not be the solution your organization is looking for. Potentially it's over-engineering what's already there, potentially it's too complex, and there are always budget constraints and team-size constraints. IDPs take a lot of effort to get working — I was on a project where, from inception of the IDP to the first live service, it took about 18 months, which is something your business might not be able to support. On the back end of that, though (that was nine years ago now), a team joining that service can start, pick up their tickets, and deploy a fully working service within three weeks — pretty impressive, but that's a lot of groundwork to go into at first.

So once it's up and running, three weeks is great for developing a fully tested and deployed product, but it relies on a lot of foundation, and your business might not be up for that investment. If you've only got a team of two developers, there's probably a lot of overhead to go through just for two people — that doesn't mean you shouldn't use guardrails, doesn't mean you shouldn't use CI/CD pipelines, but you don't have to go as far as a full-on internal developer platform.

Steps to deploy an internal developer platform

1. Basic — shared documentation, some basic scripts, just so everyone can get started.
2. Intermediate — self-service infrastructure templates, so people can have infrastructure running without writing it themselves, on their machine or shared architecture (there's no doubt a Jenkins server lying about somewhere), building stuff with basic scripts and templates.
3. Advanced — the full developer portal, with comprehensive automation. Everything you could possibly imagine is automated — create a repo on GitLab, yep, that's automated, you click a button and that repo is already prepopulated with the template. Everything can be automated to the point where developers just do the developing, commit their code, it automatically gets built, and after the commit they get a button asking where they want it deployed.

An internal developer platform isn't just a tool, though — it's a philosophy of empowerment. It's my job to be as invisible as possible — I want to provide the tools and the self-service aspect of things to developers so they feel empowered to do what they need to do without me getting in the way. The only time they contact me is if something's not quite working right, a bug, or if they want a new feature. So the IDP is your team superpower — it reduces complexity once it's set up, and it amplifies developer productivity, as in my example earlier: three weeks from inception to live deployment for a fully fledged app.

An IDP is not one-size-fits-all, it's not a template I can just give you — it's going to be unique to your organization, their choices, and their needs. The goal isn't just efficiency, it's creating an environment where developers can do their best work with the least friction. So how do we do this? We start small and iterate, kind of the agile way — we involve the developers at the platform design stage, after all they know what they want, they know how they work, and the experienced ones in your organization will know how things like to be done (that's not necessarily the best way, so we can guide them and bring those guardrails closer and closer to the ideal, using all of their experience and existing knowledge). Then we continuously measure and improve, and we want to keep things as simple as possible — simple makes our lives easier, simple makes their lives easier, and we don't want to chase complexity for the sake of it.

So what are you waiting for? Look at your current development flow — are there any bottlenecks? Where are developers spending most of their mental energy on non-coding tasks? Let me know in the comments below, and tell me about your experience of an internal developer platform too. Just to finish off, here's a little joke: why did the DevOps team call their IDP a magician? Because it turned manual chaos into automated brilliance. Not really that funny, was it — anyway, if you want to tell me your jokes, come along to the Q&A, or join us at tech-answers.club, where we can get together and support each other in all things IT, operability, DevOps, cloud, and all those wonderful other buzzwords. Till next time, may all your deployments be smooth.