Every company eventually builds an internal developer platform. The mistake most teams make is building the wrong one for their size.

At a 50-person company you don’t need a portal. You don’t need a service catalog. You need to stop making every team solve the same damn problems over and over again. Rate limiting, auth, deployment pipelines. These things should be solved once and pushed into the platform so product teams never think about them.

Early stage platform engineering is about opinionated abstractions. You pick the right defaults, bake them in, and let teams ship features instead of configuring load balancers. The whole point is that a developer starting a new service shouldn’t have to care how auth works or how deploys get rolled out. They just write code and it works. That’s the platform doing its job.

This only works if you’re willing to be opinionated. A platform that gives you twelve options for deployment is not a platform. It’s a burden. At this stage, fewer choices means faster teams. You’re trading flexibility for velocity, and that’s the right trade when you have more problems than people.

Then you grow. You hit a few hundred engineers, maybe more. Teams start bumping into the edges of those nice abstractions. Someone needs a custom deployment strategy for a ML pipeline. Another team needs fine-grained control over rate limiting because their traffic patterns are weird. The opinionated defaults that got you here start feeling like constraints.

This is where the platform evolves. You still keep the abstractions. They’re still the happy path and most teams should use them. But now you layer on tooling that lets teams pierce those abstractions when they have a real reason to. Developer portals like Backstage start making sense because you actually have enough services and teams to need a catalog. Code generation tooling helps enforce patterns across a bigger surface area. More automation fills the gaps that humans used to cover when the company was small.

The later stage platform is everything the early one was plus off-ramps. The defaults still exist. Most teams still use them. But the teams with unique needs can dig in, customize, and own their own complexity without blowing up everyone else’s experience.

The common failure mode is building the later stage platform too early. I’ve watched small companies spend months setting up Backstage when they have fifteen services and three teams. That’s not platform engineering. That’s premature optimization. Start with strong opinions. Solve the boring problems well. You’ll know when it’s time to add the portal and the off-ramps because teams will be actively fighting your abstractions. Until then, keep it simple and keep shipping.