kasperhermansen-blog/content/posts/2023-10-22-A developer platform doesn't have to be flashy.md

---
type: blog-post
title: A developer platform doesn't have to be flashy
description: Building a developer platform is a messy ordeal, this blog post will go into some of the pitfalls of building/working on one. Getting the most out of your time, and saving those pesky interns from themselves.
draft: false
date: 2023-10-23
updates:
  - time: 2023-10-23
    description: first iteration
tags:
  - "#blog"
---

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.