Indie Hacker Diaries #15: Finding Your Force Multiplier

I got an interesting email the other day from a long-time subscriber (Ross). In it, he offered some feedback as to why I haven’t had a “hit” yet:

“You change direction too much.”

Ouch.

It’s valid feedback, but there’s a big, fat, stinky why backing that behavior.

Let’s go back in time a bit.

When I started The Meteor Chef, I didn’t have a long-term vision for what I was doing. I was simply interested in Meteor, understood it well enough to start teaching it, and noticed there was growing interest in the framework.

As I started to see interest wane in Meteor (both on the developer side and in the team building Meteor), I started to think about what was next (I hinted at this in a previous email).

It wasn’t that I didn’t want to work on Meteor long-term (my archives have a lot of five and ten year out ideas that never got to see the light of day), it was that I realized Meteor, for better or worse, was no longer growing (a big problem for a small business hitched to it). That meant that, in order to keep my business alive, I had to make a choice: stay attached to something that had unclear prospects, or move on.

I knew that the tech behind Meteor was solid enough, so I decided to stop just being “the Meteor guy” and took what I’d learned over to Clever Beagle, helping others to build their own apps. But, as the JavaScript ecosystem continued to expand (and the routine “why don’t we use this” questions piled up), I was faced with a dilemma: start supporting a ton of different frameworks, or die.

The reason I didn’t do that was that I knew first-hand how hard it was to not just build tools for one framework, but also to teach it to others every day. Had I gone the multiple frameworks route, I would have been stuck supporting who-know’s-what tech for a long, long time. I say “stuck” because I would have known in the back of my mind that those were the wrong tools for achieving what my students were after. It’d be a straight-up lie.

So, that’s how Joystick came about. I realized that if I took the Steve Job’s “walled garden” approach for Apple and applied it to JavaScript, I’d be able to think more long-term about things. By controlling the tech, I could teach others on a stable ground that would only shift when I wanted it to. That meant, hypothetically, that my business would be far more stable.

But to get there, I knew I had to make an insane bet. First, I had to figure out how to build my own framework, and second, how to get people to use it and trust it.

That brings us back to Parrot.

About 2 years ago, mid-way through Joystick’s development, I realized that just telling people Joystick was great was a no-win strategy. They’d been burned by countless frameworks/developers and, perceptively, I was just another huckster at the code carnival.

That’s when I figured it out. Instead of trying to teach or convince people that Joystick was great, I’d have to show them.

Quick note: even though I had the idea two years ago, I had to build Joystick up to snuff in order to execute on it in a way I knew would work.

How would I do that? I’d build apps. As many as I could. As fast as I could.

Parrot is the first of several apps I want to build. I knew that Joystick sped up the development time on projects significantly from my work on client projects. But Parrot is the first time I’m really pushing Joystick per my own standards.

I picked up this idea nearly a decade ago from a book called “The E-Myth.” The crux of the book is to think about your small business like a franchise (even if it’s not intended to be one). One of the tips the book gives is creating a “prototype” for different ideas in your business.

In the book, “prototype” was used to refer to a process, offering, etc., that you could infinitely tweak to perfection. It was a test bed for what you’d deliver to customers later. From the E-Myth blog:

Your business model prototype puts your ideas to the test in the real world. It takes your hypothesis (that this special touch will generate more loyal customers) and puts it into action. And your only criteria for measuring that is: Does it work? Once you’ve completed a prototype of each of your systems, you should be able to say to any employee, “Let me show you how it works,” and expect them to run it the way you would.

That is what Parrot and the other apps I’m building are doing. They’re a way for me to test things out and find the edge cases in Joystick, Mod, and Push, while also creating additional revenue streams. Yes, that effort means the evolution and release of those things slows down, but long-term, it means that my claim of “it just works” is fucking bulletproof.

As I’ve observed the JavaScript landscape over the past few years, I grow increasingly confident in this strategy every day. Unfortunately, a lot of the frameworks have become sloppy (X is rife with stuff like this), leading to sloppy software being built on top of them. It may be dumb luck, but I consider this outcome a massive opportunity.

But not just for me.

As an indie hacker, if you have an idea for taking an existing idea and making it better: this is your time to strike. All of the VC-backed businesses are starting to struggle because of a few key problems:

1. Insane payrolls. We all know that it doesn’t take thousands of developers to maintain an app. But investors like headcount growth (early on) and this quick sand has snared nearly all big startups into hiring like mad (made possible by ZIRP money). Now, they’re starting to let people go, and if they haven’t already, scaring off the founders who held the real vision for the product.
2. Degrading products. In a race for growth, products that started out simple have ballooned into “who is this for” nightmares. A lot of the winners of the past decade and change are rapidly becoming the has-beens.
3. Bureaucratic complexity. Similar to payrolls, the massive headcounts also create a kludgy, impossible to ship environment. “Move fast and break things” really has broken things. To such an extent that shipping a dark mode is considered a “feature.”

I could go on. But hopefully the point resonates.

Amidst all of the economic uncertainty and chaos, now is the time to find your force multiplier—development speed, design quality, industry knowledge—and work it to your advantage. By the time the economic dust settles, you stand a chance to come out on top as a success.

This is the bet I’m making. My goal is to take advantage of the VC-created techno-dystopia and create better products. To do it, I’m going to use my own force-multiplier of Joystick, Mod, and Push. I know what I’ve built is solid, but now, as those tools crystalize, I’m moving on to what’s next.

Show, don’t tell.

Ryan