So you’ve decided to build your own custom internal developer platform.

Congratulations! This is an important step for any product or engineering org. Whether you’re dealing with overly long release cycles, having difficulty cataloging your tech stack, or just wanting better consistency and collaboration across dev teams, a developer platform can be just the thing to give people the structure they need to build incredible products. 

But also: be careful. There’s great danger here. The path up the mountain seems clear and easy, but it’s paved with the bones of the many teams before you who’ve tried and failed to reach the summit.

For as simple as developer platforms seem, the uncomfortable fact is that any project looking to build one must always run through the single most vexing challenge in all of technology: The Dreaded XKCD Standards Dilemma.

Image by XKCD

Here’s how this usually plays out: 

In the beginning, engineers mostly build the infrastructure that runs their code themselves. Developers build and maintain their own “helpful” scripts. Team A keeps a homegrown Bash file that runs 30 lines of near-magic. Team B pushes an all-in-one Docker approach with a few random environment variables. Team C prefers a continuous integration pipeline that runs on a personal Jenkins cluster under someone’s desk. Each team believes its approach is the best. They see no reason to change, because everything works—most of the time.

Your organization decides this chaos must end. Leadership introduces a DevOps role. The hope: unify these scattered tools under one cohesive system. The DevOps lead starts small, handles environment requests by hand, then tries to save time with automation. 

Soon enough, they decide to integrate all of these automations into a self-service portal. This is the big moment: “One unified platform to rule them all.” A few teams sign up, only to discover missing features or confusing permission models. Another team demands custom build steps for an obscure framework. The DevOps lead patches those in. More edge cases pop up, which leads to more hacked-in code, which over time turns the self-serve portal into a Frankenstein’s monster that even the people maintaining it only halfway understand.  

Meanwhile, half the developers don’t even try. They keep their beloved scripts because the platform doesn’t meet their exact needs, and they continue to ping DevOps on Slack whenever they run into an issue. The platform languishes. 

This whole exhausting process takes about 12 months, and at the end of it your bosses wonder why you tied up so many resources for that long just to add a 15th way of doing things to the pile.

Building a Better Developer Platform

It doesn’t have to be that way. 

The secret to building a better developer platform is treating it like a product, and your internal developers like consumers. Like consumers, they won’t automatically use your platform just because it’s there. They need to want to use it. And for that, you’ll have to sell it to them.

The answer to both of these challenges is making your internal developers more of a partner in building your platform.

Which, we can tell you from experience, is way easier said than done. We’ve spent the past 2 years diving deep into this problem space to create a product that isn’t just a better platform but rather infrastructure that helps anyone build a better platform. Along the way we’ve learned a lot about how these projects succeed and how to avoid the most common pitfalls. We’d like to humbly offer 3 big ideas that can help make your project to build an internal developer platform more successful.

Learning 1: Let go of your ego

Building an internal developer platform often spawns strong opinions. DevOps folks spend their days neck-deep in logs, environment configs, and deploy scripts. They see glaring inefficiencies and assume their solutions must be the best path forward. Yet this mindset can alienate developers who only encounter these problems sporadically.

Letting go of your ego requires one major shift: remember that your daily operational headaches might not top everyone else’s priority list. That advanced automation you love might baffle a front-end team that mainly wants a quick-start environment and an easy way to see logs. The gap between your worldview and theirs can kill adoption.

Accept that you are not the only user of the new platform. Bring other people in even at the idea stage to make sure you’re addressing real needs as you develop your product thesis and set your project goals.

Hold listening sessions. Ask them, “What’s your biggest friction?” or “What do you ignore because it’s too cumbersome?” You might discover that your prized pipeline is overkill and that a simpler solution addresses their real pain.

This doesn’t mean you abandon your DevOps expertise. It means you apply it in a way that respects others’ time and cognitive load. Provide simpler paths for casual users, while preserving powerful tools for advanced teams. 

Let go of your desire to build the Perfect Ultimate Workflow. Let your end users guide you toward the streamlined, day-to-day problems that actually matter. When developers see that you’ve set aside grandiosity and catered to their needs, they’re more willing to experiment—and more inclined to stick around once they do.

In short, treat this less like an internal tool that you’re building, and more like a product that you’re building for a diverse market.

Learning 2: Engage early, but engage smart

You can’t build a product in a vacuum, of course, especially one as complex as a developer platform. The most brilliantly coded and clever design in the world won’t matter if developers find the interface alien and the goals irrelevant. Your users will always know what they need better than you do (although they will probably struggle to articulate this if you ask them). If users think something feels wrong, then they’re always right, even if neither of you yet understand how to fix it. 

This makes early outreach and feedback key, but also painstakingly difficult. It requires focus. The worst thing you can do is to scatter your energy across too many teams, because this will dilute your efforts and muddy the clarity of the response you get from participants.

Instead, choose a handful of “power users” who have high influence within the org. Maybe they maintain a flagship product or they’re known for adopting new tech. Look for the kind of engineers that other engineers go to when they have a problem. Work closely with these teams and test iterations with them early on. 

Uncover the real pain points they face: long environment setup times, endless config duplication, or confusion around ownership during crisis situations. Then address those issues directly, test your implementations with them, and iterate until you both agree you’ve got it right. Just as a consumer product beta doesn’t enter general availability before it has at least a few happy reference customers, you shouldn’t formally launch your platform until both you and your initial pilots are satisfied that it meets their actual needs.

The goal isn’t just shipping software; it’s winning hearts and minds. When your pilot teams see an immediate improvement—like cutting onboarding time from a week to a day—they become natural advocates. Their positive experience resonates more than any top-down directive. Suddenly, you have an organic marketing force.

By focusing your initial efforts, you avoid the trap of pleasing everyone at once. You gather meaningful feedback and iterate quickly. That speed helps you refine the platform before rolling out to a wider audience. It also builds excitement. Instead of overwhelming your dev community with half-baked features, you deliver a polished product to a smaller group, then watch the good word spread.

This approach sets a strong foundation. It keeps you from overextending and allows you to make real progress with real users. Then, when the rest of the company clamors to try the new platform, you’ll have proven wins and a stable codebase—an appealing combination that boosts adoption across the board.

Learning 3: Make user interface a priority

What you’ll probably learn through all this engagement will be surprising to someone who’s spent their career mostly working on internal tooling: user interface really matters.

The easiest way to kill adoption is by offering an interface that seems trivial to DevOps but feels overwhelming to developers. A typical DevOps pro looks at a couple of CLI flags and a small YAML file and thinks, “This is simple.” But from a developer’s perspective, that’s yet another tool to master in a day already dominated by shipping features, reviewing code, and fighting deadlines.

Your goal is to minimize the extra overhead. A developer doesn’t want to read a 10-page doc on environment variables just to spin up a staging instance. They likely care more about building or testing their next feature than learning the nuances of your automation scripts. If your platform adds friction or confusion, they’ll revert to old habits—and you’ll be back where you started.

Consider empathy your best tool. Put yourself in the developer’s shoes. Can they accomplish basic tasks in a few clicks or a single command? Are errors clearly explained? Do the default settings work for the most common use cases? When in doubt, make it even simpler. 

Yes, you may thrill at seeing every possible config option, but remember that your platform must serve people with varied skill sets and different priorities. By reducing cognitive load, you gain adoption. Folks will actually enjoy using the platform, rather than seeing it as a chore.

Once developers trust the interface, they’ll come back to explore deeper features, ironically making the entire organization more efficient. Ease of use isn’t fluff; it’s the bedrock that ensures all your fancy automation doesn’t go to waste.

Wrapping Up

An internal developer platform doesn’t have to become another unmaintained script or an automation you dread interacting with. Here’s what matters:

• Let go of your ego: Build for the real needs of every team, not just the daily frustrations of Ops.

• Engage early, but engage smart: Identify key power users to pilot your platform and generate enthusiastic advocates.

• Make user interface a priority: Keep the experience simple, empathetic, and geared toward helping developers do their jobs fast.

Following these three points can transform your platform from a rarely used extra step into an essential tool people actually enjoy using. Of course, it’s not always easy—organizing complex infrastructure at scale rarely is—but if you approach it with the right mindset, it can save months of frustration and deliver real results.

If you’re curious about a solution that aims to make building a better internal developer platform easier than ever, check out Tempest. We’ve spent years refining a system that handles the heavy lifting behind the scenes, so you can focus on what you do best: building great software for your customers.