journal // Oct 18, 2024

Indie Hacker Diaries #23: The Iterative Process

Indie Hacker Diaries #23: The Iterative Process

I have a dirty secret to share.

Since it launched, I’ve barely used Parrot to generate code. Instead, I’ve been falling back to Claude chats and the occasional Cursor chat.

Why? Well, in the development process for Parrot, I found myself having a bit of tunnel vision.

I knew that being able to generate code using your own coding preferences was crazy helpful, but I also knew that the “snippets” focus I took wasn’t quite right.

Do I use code snippets in my day to day work? Yep. Every day.

But when it comes to generating code, a one-shot solution—and specifically, a reusable code snippet—isn’t typically what I need. What I need is more bespoke. A solution to a problem in a specific project—not a one-size-fits-all chunk of code that I’ll use again and again.

More often than not, when it comes to generating code I’ve found that I have to iterate on the code quite a bit. Nudging the LLM toward the working solution as part of a conversation, not a one-and-done solution. I also find myself having questions about what’s happening, why, and how the code might improve.

As of today, Parrot doesn’t make that easy. And so, I’ve started the iterative process.

A week or two ago, I spent some time sketching out some alternative UI approaches I could take to accomplish the above. What I didn’t want to do was throw away all of the work I did or rewrite the entire product—a mistake I’ve made in the past.

To figure out the best approach, I went to the whiteboard in my office and started moving parts around. One of my favorite techniques to aid in this process is talking to myself. Out loud, discussing the pros and cons to an approach. Erasing. Redrawing. Thinking through the “what ifs” both on the UI and back-end.

The thing I’ve learned over the years is that it’s very easy to fool yourself into thinking you “got it” with a new design. You go to sleep excited, convinced that what you just came up with is going to change the game forever. You start writing code. Before you know it, you’re deep down a rabbit hole, forced to choose between scrapping the new direction or committing to something you know isn’t right.

Instead of just diving into building, now, I make a point to “argue” with myself.

I ask myself questions like:

  • “Are you sure you’re right? What are you missing?”
  • “Are you just building an existing product? What’s different about this?”
  • “How might this approach be confusing to others?”

The point being to avoid letting the excitement of a new idea (really, an excuse to do what I love, which is build stuff) getting me into quicksand.

Only once I’ve gotten answers to those questions and considered how those decisions will affect the perception of the product do I start building.

And this is the iterative process I follow today.

In the event that a new direction fails to pass the rigor of the process above: I wait. Either indefinitely, or at least for a few weeks. I’ll put the idea down and focus on something else.

That’s the benefit of working on multiple things at once. Though it can often be confusing to the people that follow my work, focusing on multiple ideas or projects at once is intentional.

It may seem like my efforts are somewhat-schizophrenic week-to-week, but I’ve found that having multiple things to focus my attention on keeps me—and whatever I’m working on—out of trouble.

The tricky part is having the discipline to come back to the ideas you’ve put down once you’ve completed the thinking and deliberation phase. To not get distracted by yet another shiny new toy.

To help with that, I use the “talking to myself” approach to also ask questions about the general direction I want my business to lead. To decide whether or not what I’m building fits the long-term vision or goal I’m aiming at.

You may have noticed over the past few weeks that I’ve started to lean into the “indie hacker” term. As part of one of my deliberation phases for where I wanted to take CheatCode, I started asking “who is all of this for...who is the ideal customer?”

What I realized is that, over the years, the most consistent type of customer I’ve served is the solopreneur. People just like me, working to find an idea that “sticks” that they can turn into a viable business. More specifically, I’ve worked with a lot of indie hackers. People who have—or are working to build up—technical skills, eager to build and ship software.

As I make decisions about how to iterate on the businesses I’m running (or am in the process of building), I make a point to ask “does this serve that market?”

When the answer is “no,” I pump the brakes. Even if I think the idea is good.

The reason why is that it’s far easier to work on a lot of different stuff if the market you’re serving is the same or similar. Not only is it technically easier, it’s also less cognitive load. There’s enough overlap in customer expectation—and how things are built—that what’s true for one product is likely to be true (to some degree) for another.

Is this bulletproof? Not always. But it definitely helps. It also creates the potential for connecting the dots and finding new ideas you wouldn’t have considered between projects.

As I start to finalize the next iteration of CheatCode (officially, the developer tools and consulting side of my business), I’m constantly asking if the other software I’m building will “fit” the people I’m targeting there.

Just like iterating on the software itself, it’s a constant process of asking questions, tweaking the details, and pushing back on my own exuberance before committing down a path.

Learning to do that has really saved my bacon over the years. I’d bet that if you tried it with your own work—even if you’re just focusing on a single idea right now—It will help you, too. Get good at calling “bullshit” on yourself and knowing when to take a beat before moving forward.

If anything, following this process makes you a much sharper business person.

Instead of getting stuck working on something that’s a dud (or doesn’t excite you), you always have something fun to focus on. Even if it’s not quite what people expected, there’s always something shipping and you’re always making progress toward your ultimate vision.

All I can say is that it’s definitely worked for me. Not just to help stuff getting out the door, but to keep me excited to sit down and do the work, even on the days where I really don’t feel like it.

Written By
Ryan Glover

Ryan Glover

CEO/CTO @ CheatCode