Indie Hacker Diaries #20: The Perfectionism Problem

For the better part of the last three years, I’ve been working on building a deployment service for Joystick, called Push.

I started in January of 2022 with little-to-no understanding of traditional dev ops. I had gotten my hands dirty with Kubernetes before, spinning up my own cluster and getting deployments to work, but my skills were limited.

But for this service, I asked the same question I asked when I started work on Joystick: “is there a way to make this simpler?”

It turned out, yes, much simpler.

One of the unfortunate realities of modern web development is that complexity sells. People like acronyms, buzzwords, reams of documentation, and any excuse to spend time noodling with a new piece of tech.

While tools like Kubernetes and Docker have the right intent, for most developers and products, it’s overkill.

This is what I realized right as I was starting work on Push. I didn’t need some crazy, auto-scaling behemoth of all these nodes and pods and hornswaglers and vermicious knids. I also knew that the types of developers who depended on Joystick to build their app wouldn’t need all of that either.

What they needed was one or a few servers that would run their app consistently and reliably. In the most extreme scenario, they’d need a load balancer to route traffic to one of several instances. That’s it.

So, that’s what I built.

The first version I did in 2022 was...okay. It worked, well enough for me to redeploy the CheatCode site when my Kubernetes cluster got nuked by a mandatory cluster version upgrade, but it was clunky.

I had over-complicated the process of bootstrapping the server (installing the necessary dependencies to run a Joystick app) in a way that made the bootstrapping process unreliable. It would work, most of the time, but in some cases it would get stuck in a loop of “bootstrap failed” and never complete.

So, by 2023, I had a rough version of the service but decided to give it another go. This time, I made the mistake of creating what I call a “monument to engineering.”

I thought that if I could encapsulate the bootstrap steps and add a combination of verification steps and retry logic, I could make bootstrapping more stable.

I was right, but...the way I built it required multiple services spread out across multiple servers. I had split off the customer-facing app, provisioning (where I created the server and bootstrapped it), and monitoring all into their own services.

This made me feel like a genius, but it also added a ton of cognitive overhead.

Up until the last few weeks, this has been the reality of Push. I intended to ship it in 2023, but in the back of my mind, I knew that while it worked, offering it to customers would have been sketchy.

Not because it would cause issues with their own sites (uptime of sites deployed with Push since v1 have easily been in the four-to-five nines range), but because if they did run into issues (or for some reason, Push and Joystick took off), I’d be under water fast.

That’s why I’ve more-or-less shelved Push until now, save for personal use. I knew it was close, but it wasn’t right.

Over the past few weeks, I decided to take all of the lessons I’ve learned over the past couple of years and rebuild Push. Not because I had to, but because I knew that I wouldn’t be able to sleep well (figuratively and literally) if I started selling a service to customers that I wasn’t 100% certain was delivering the value I claimed.

And this is what I want to share with you today: knowing the difference between perfectionism and quality control.

Perfectionism is the literal pursuit of an absolutely perfect end-result, typically doing so in isolation or obscurity, indefinitely.

The problem with chasing perfection is that it’s next-to-impossible to define what perfect means, and so, it’s easy to sit and spin your tires indefinitely.

It might make your ego feel good, but it doesn’t move you forward. Perfectionism is the artist who never ships. The smug loner who never really tests their ideas in reality but is convinced if they did, they’d decimate everyone else.

Quality control is the commercial cousin of perfectionism. It has different goals. Quality control is knowing when to say “this isn’t right” or “this doesn’t work as well as it could” and knowing when to go back to the drawing board.

It’s understanding the difference between a working prototype and a production-grade offering.

It’s knowing, tacitly, that if you were to ship what you have today, it wouldn’t be the absolute best experience you could offer to customers. It’s a choice, rooted in respect for the others consuming what you’ve built, not vanity or self-glorification.

A self-admission that you can do better, should do better, and that the sacrifices required to bridge that gap are yours to shoulder alone. And if you get it right, the rewards are yours, too.

To put in a visceral context: the Boeing team skipped quality control on their planes, leading to several disasters that could have harmed real people. I can guarantee they didn’t want doors falling off their planes mid-flight and I don’t want deployments failing on my customers.

Sure, this may seem like an extreme attitude. And I’m certain that you can come up with 101 reasons for why I’m wrong (and, to be fair, you probably wouldn’t be wrong yourself). Granted, the type of software most people reading this (myself included) are building are not under the same level of scrutiny as an aircraft.

But the point stands. If you have the ability to do something right, do it. It’s very easy to say “meh” and think you’re going to fix later. We all know, though, that more often than not, this is just a convenient lie we tell ourselves to feel better in the moment (or placate a manager).

Am I happy that it’s taken nearly 3 years to get Push to the level of “right” that I wanted? Of course not. But now that I’m here and can trust what I’ve built works insanely well, I can proudly offer what I’ve built, going to sleep knowing that I put in the effort to not just to make it work, but make it right.

I’ll leave you with this excerpt from a response to a reporter by Steve Jobs that neatly sums up what I’m getting at: “we just can’t ship junk.”