Indie Hacker Diaries #34: The Boring Sh•t

You’re probably getting tired of me talking about work on Mod, but hey, that’s what I’m up to at the moment.

This week, I’m doing the thing that every developer loves to hate: documentation.

Fortunately, there’s not a lot of of moving parts to Mod, so documenting its behavior has been fairly chipper. Earlier this week, though, I had a bit of an epiphany.

Originally, my goal was to just document how to use Mod with a plain HTML page and a Joystick app. But then I realized...”there’s nothing about Mod that can’t work with any other site/framework, you should add some extra examples.”

I also realized that by adding integration docs for other frameworks, it doesn’t really hurt me. It only increases the odds that Mod is adopted. Is it something I really, truly wanted to spend my time on? No. That’s why I built Joystick—to get away from the chaos of other frameworks.

But, getting developers to adopt a brand new framework is tough. It’s like trying to feed mashed broccoli to a baby. You can make all the airplane sounds you want, but that spoon ain’t going in, bro.

So, I decided to meet developers in the middle. They may love how Mod looks and want to use it in their app, but if it’s not easy to integrate, they’re less likely to try it out.

I decided to cover as many of the known, popular frameworks as I could: Rails, Django, Laravel, Astro, SvelteKit, Vite, Next.js, Nuxt.js, and of course, Joystick.

This was a bit of a slog at first as the big gotcha with frameworks like Rails and Django is getting your environment to play nice. Here’s a live look at me doing that earlier this week:

I eventually figured it out, but something interesting happened. In the past when I saw a new framework getting hyped, I might dig through the docs, look at some example apps, and rather quickly form an opinion on if its approach was right for me.

But this time, I was forced to get my hands dirty. I had to install and set up projects for all of the frameworks above. That gave me an opportunity to really compare how Joystick stacked up against the competition. I may be biased, but I’m comfortable saying that the simplicity of Joystick’s integration was starkly noticeable compared to the others (save for Astro, which kudos, that took all of five minutes of reading the docs to get rigged up).

And this is important. In order to know if your thing is really better than the competition, you can’t just say it. You have to dig in and really experience the pain of the alternative, getting up close and personal with the chaos. That’s how Joystick came to be in the first place: I knew, first hand, what it took to build an app with JavaScript and the often teeth-grinding experience of chasing the whims of framework developers.

Was this fun to do? No, not really. This is the “boring shit.” The stuff that you don’t really want to do but you know it will ultimately serve you well in the future. Tracking calories. Going to the gym. Writing documentation for tools you don’t use but know others do. It sucks in the moment, but the potential dividends it generates make it something you can stomach.

There’s immense wisdom here. From my own experience, the stuff that had the greatest impact on my success has always fallen into this category. It’s rarely if ever the stuff you want to do that helps you; its the stuff that you really, really, really don’t want to do.

When it comes to your own SaaS/product, think about it this way: what can I do (or should I be doing) to increase the odds that people adopt my thing? Ignore the inevitable pain response to things that aren’t fun. Just shut up and do it. Realize that doing the boring shit is just part of the road to success. See it for what it is, but also look for nuggets of wisdom or truth in the process (“hey, my thing isn’t so bad after all”).

A riff on Mick Jagger’s “you can’t always get what you want”: you can’t always do what you want, but sometimes you (have to) do what you need.