A developer platform doesn't have to be flashy

2023-10-23

Your life as a Platform Engineer revolves around the developer platform, a hodgepodge of pre-built and homegrown tools. But let’s get real: not all tools are equally useful or even necessary.

The Honey Tooling Trap

We all have our darlings; Kubernetes, Dagger, Docker, but falling head-over-heels can be dangerous. Soon you're building a UI not to solve problems but to admire YAML going to production. It’s like creating a theatre for paint to dry. Are you really building a spectator sport?

The real mistake isn't favoring a tool; it's pushing that tool onto your users. What you end up delivering is a leaky abstraction. Worst case? Years invested in a platform with no cohesive experience to show for it.

What a Platform Should Be

A platform doesn't need to be a Swiss Army knife. It should, however, shield users from internal complexity. Giving raw access to Kubernetes? That's a chaos generator.

You’re not building a consumer product; you're building a tool that your developers are somewhat obligated to use. It doesn't need to be feature-complete; it needs to be useful and maintainable. Aiming for a pristine API when no one’s losing sleep over it is misplaced effort.

The Danger of Complete Flexibility

Over-flexibility bites you back. Take lunarway/shuttle, our CLI tool, used for sharing deployment strategies (think golang service preset). We let users override scripts, which made internal changes a hellish ordeal. Flexibility done wrong can fragment your platform until you're supporting as many versions as there are teams.

Striking the right balance is key. Not every problem requires a sledgehammer; sometimes a simple mallet will do. Aim for a platform that’s robust but not a maze, flexible but not a free-for-all. The important bits are keeping it intentional.

Being at the mercy of others

Having a strong opinion matters, but it's crucial to adapt when better ideas arise. Leadership like an Architect or Tech Lead gives you the confidence to build intentionally. Without buy-in, you risk building a golden hammer sitting collecting dust.

It's a two-way street: meet user requirements or risk shelfware. Never underestimate the value of feedback in building a robust platform.

Also remember that users want to solve their needs, they don't care about what the platform does, or works. You have to take feedback, and apply it with your style, opinion and view of the land. It is okay to just say thank you for feedback, and ruminate on it.

Maybe you need to solve their exact need, but can you get some synergy by spending a week extra on your tool to solve the problem globally, maybe, maybe not. It is a decision you need to make.

You don't need that fancy UI

I think most Platform Engineers have spend a good amount of time building a fancy UI to solve a problem, which was barely used. While your little shitty shell script you spent 15 minutes on, and distributed via. slack, is seeing use everywhere. It sucks and doesn't feel right.

But here you have to take a step back and reflect. Should you really have spent 3 months building a glorified React app driving copious amounts of graphs, before finding out if there is actually a need for such a thing?

Coffee-Station Testimonials

The reason why your shitty shell script is used so much, is because it was born to solve an immediate need. When you've got a ticketing system, or public channel where people can post their problems, usually only the most confident members of a team, usually a tech lead would be the ones asking questions on their squad members behalf, especially if they're an intern. This means that one simple ticket, could potentially have 3-4 very enthusiastic interns behind it.

Simple solutions can bring real value, especially for enthusiastic interns who might not have the confidence to speak up, but will spread your dirty laundry like a virus, if it seems remotely useful.

Trimming the fat

You should always keep your platform lean enough, to have a gateway for new tools, that as they grow into maturity, will get a new fresh coat of paint, or redone etc. At some point you will end up with a host of mature, robust tools, that nobody need to touch, except bump for security fixes. Tools that are in the experimental phase, and tools that you're working on replacing, because it doesn't fit in your strategy. But none of these need a UI unless there is an actual need for it, or your users are simply incapable of using a terminal app.

In our experience, it has been as easy if not easier to ship lunarway/shuttle features, than it has been to ship various backstage plugins (insert fancy UI of choice here), which all are very pretty and seemingly user friendly. But most people have to get a feel for how a UI works, because there is no standard for how to build complex user inputs. There is for terminal apps on the other hand.

Conclusion

Start simple. CLI first, UI later—if needed. Your goal should be a platform that balances flexibility, functionality, and complexity, not a collection of shiny, unused tools. Value is derived from utility, not aesthetics. The more aligned your tools are with the real needs of your users, the more impact your work will be. I feel like preaching to the choir, but I've been surprised more times than I'd like.