feat: add blog contents

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

@@ -0,0 +1,119 @@
+---
+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.