I Built a Silly CLI Tool, Just Because I Can

No roadmap, no real need — just an engineer having fun again.

Why I Built This Silly Little CLI Tool?

There’s a part of me that still lights up when I ssh into a Raspberry Pi or see logs scroll past on a terminal. Even though my job title has grown, my love for getting my hands dirty hasn’t gone anywhere. I’ve been doing more engineering leadership work lately—mentoring, aligning org goals, enabling teams, writing roadmap docs. And while I deeply enjoy shaping how we build and scale systems, I missed something very basic: the raw, low-stakes fun of building stuff for no reason.

So I built Mantra, a silly little CLI tool that does a bunch of random things—like pinging a website, checking HTTP headers, doing DNS lookups, and even adding a few numbers. It’s not groundbreaking, but that’s the point. It’s not supposed to be.

It’s me putting on my “just an engineer having fun” hat again.

I Missed Being a Geek

I'm the kind of person who self-hosts their entire digital life. Seriously—I've got a Kubernetes cluster running on Raspberry Pis at home. Grafana dashboards track everything from smart light usage to DNS queries. I run a local DNS sinkhole to cut out ads. My NAS is packed with movies I’ll probably never finish watching. If something can be self-hosted, it probably already lives in my home lab.

This stuff doesn’t have to be perfect. It doesn’t even have to be useful to anyone but me. I just love that feeling: learning, tweaking, experimenting. Breaking something and staying up late to fix it. Writing GitHub Actions that somehow works. Debugging issues that no one else will ever care about. That’s my fun.

Mantra = Formula

The name मंत्र (Mantra) comes from Hindi, meaning “chant” or “formula.” Traditionally, a mantra is a sound, word, or phrase repeated to focus the mind or invoke inspiration.

In the context of this project, Mantra is like a personal formula—a simple set of commands that help me focus, have fun, and reconnect with the joy of building. It’s a reminder that sometimes, the smallest routines or tools can bring clarity and energy to complex days.

Mantra is my little playground. I didn’t want to build the next productivity tool. I just wanted to build something. Something that lives in the terminal. Something I could ./mantra webstatus sanusatyadarshi.com at 9 p.m. after a long day of meetings and still feel like an engineer.

$ ./mantra webstatus sanusatyadarshi.com
The response from sanusatyadarshi.com is: 200 OK

I picked Go because I like how it feels—pragmatic, tidy, and fast. And because I missed the satisfaction of building something from scratch and watching it actually work. Mantra checks if a website is alive. It shows you headers. It does a little math. It’s not a full suite of tools, it’s just a weird little robot that does things I find fun.

I Treated It Like a Real Project

Even though this was just for fun, I couldn’t resist going the extra mile. I set up proper CI/CD with GitHub Actions. I created versioned releases with changelogs. I even tagged commits like I was shipping production software.

Why? Because it felt good. It reminded me of the pride that comes from seeing something go from a vague idea to a packaged, released binary. And honestly, if you're going to write code, why not write it well?

Hacking Makes Me a Better Leader

Here’s the thing people don’t talk about enough: side projects make you better at your “real” job—even if that job isn’t coding full-time anymore.

When I build things like Mantra, I reconnect with the parts of engineering that frontline devs deal with every day: messy bugs, docs that lie, error messages that make no sense, tradeoffs that happen in the moment. It keeps me close to reality. It makes me more empathetic. When a dev on my team says “debugging this took forever,” I actually get it—because I just spent two hours wondering why a slice wasn’t updating.

It also keeps my judgment sharp. It’s one thing to talk about system design in a meeting. It’s another to experience why a library’s abstraction is frustrating or how an interface breaks down in practice. Even small tools like Mantra remind me that details matter—and so does developer experience.

And frankly, building things with no business value makes me better at recognizing what does have business value. It keeps my BS radar strong.

TL;DR

I built Mantra because I missed the feeling of making something silly, simple, and mine.

It’s not big. It’s not important. But it reminded me why I started writing code in the first place—and why I’ll never stop, no matter what title I hold.

When Platform Teams Succeed — and When They Don’t

Success for platform teams isn’t just about building great tools. It’s about getting the whole company to move with you. And for that, you need the right kind of backing.

Disclaimer: Views expressed are my own and do not represent those of my current or former employer(s).

Summary

Platform teams win when they have the authority to drive change, not just recommend it. That means sponsorship from the top, alignment with business outcomes, and the ability to say, “This isn’t optional.” Without that, your roadmap becomes a graveyard of unadopted migrations. And your engineers? Burnt out and invisible.

---

Platform Work Is Critical—and Often Thankless

If you’re on a platform team, you’re probably doing the invisible work that makes everything else possible: infrastructure, developer experience, observability, CI/CD, and org-wide migrations.You power the foundations of SDLC at your company-but hardly anyone cares.

Why?

Because you don’t ship customer features. Your metrics live in internal dashboards, not company OKRs. So when you say, “We need every team to migrate by Q3,” what you usually hear back is:

“We’ll put it in the backlog.”

That’s where the success or failure of platform teams starts taking shape.

When Platform Teams Fail

It’s rarely dramatic. It’s a compounded burden of ignored deadlines and growing disillusionment.

• Migrations stall. Nobody pushes them. Product teams are focused on features.
• Morale dips. Engineers working on infra or devtools feel unheard, sidelined or even ignored. They become the internal help desk.
• Shadow tools emerge. Teams build their own pipelines or tweak infra, defeating standardization efforts.
• The team loses credibility. And once trust erodes, it’s hard to recover. The platform team becomes a cost center instead of a force multiplier.

The Fix: Top-Down Authority

Successful platform orgs are not consensus-driven. They are mandate-driven. And that mandate comes from executive sponsorship—VPs, CTOs, even the CEO in some companies.

When leadership is aligned, three things change:

1. Org-wide clarity. Migrations aren’t “optional.” They’re tied to core goals: uptime, velocity, scaling bets.
2. Incentives shift. Product teams prioritize the migration because it’s tied to their own success metrics.
3. You get support. The PMs, TPMs, security teams, and budget you need show up—because the execs said so.

You don’t need to beg for adoption. You drive it.

This kind of sponsorship turns platform work from a "nice-to-have" into a business-critical priority.

Case in Point: Driving Migrations

Let’s talk migrations — the litmus test for platform teams success.

• Without support: A new performance optimisation tool is rolled out, but only 30% of teams adopt it. The rest don't prioritise it or don't adopt it due to incompatibility(due to prior unfinished migrations).
• With support: Migration deadlines are communicated org-wide. Dashboards track adoption. Engineering leaders follow up directly. And suddenly, everyone’s moving in the same direction.

This isn’t pressure—it’s alignment. Alignment gets adoption. Adoption gets results.

What Platform Teams Can Do

Even if you’re not a Principal Software Engineer with a decade long tenure at the company, here's how you can tilt the odds in your favor:

1. Tell compelling stories. Translate technical initiatives into business impact: “This migration will reduce infra cost by up to 15%.”
2. Build alliances. Partner with security, compliance(finops/engineering office etc.), and product leaders. Their needs are often aligned with yours.
3. Push for sponsorship. If a migration affects the whole company, make the case to engineering leadership early. Don’t wait until adoption stalls.

In the End: Platform Is Political

Success in platform engineering isn’t just about great features and offerings. It’s about influence.

Yes, the systems matter — but so do the people who shape how those systems are adopted.

When leadership recognizes the strategic role of platform teams — and gives them the mandate to drive change — the results are transformative: faster delivery, higher reliability, happier developers.

When they don’t? The tools gather dust. And the people who built them quietly leave.

Final Thought

If you’re in a platform team today, ask yourself:

“Do we have the executive support to drive change — or are we just building great tools no one will use?”

If it’s the latter, start the conversation. Your success — and your sanity — might depend on it.