What Indie Development Has Taught Me

When I started indie development, I thought the hard part was building the product.

That was the part I knew how to think about. An idea could be broken down: architecture, interfaces, data, edge cases, release. Keep solving those problems, and eventually there would be something to put in front of people.

I remember submitting my first app to the App Store, and how genuinely excited I was when it was approved. It felt like crossing some invisible line.

Later I learned that building it was the small step.

For the next few months I checked App Store Connect almost every day. A new user would show up; I’d feel briefly encouraged; the next day I’d check again. Usually they were gone, and the number I’d been so pleased about settled back to where it started.

At first I read this as “people don’t know how to use it.” That’s the trap engineers fall into most easily: if someone doesn’t use the product, the onboarding must be unclear, a feature must be missing, an interaction must need work. So I added features, changed the onboarding, studied other products, and eventually started feeding my own flows into AI tools and asking, over and over, where I was going wrong.

I also tried promotion. Some of it looks fairly naive now. I made cute AI-generated videos and imitated the way commercial products advertised on social media. At the time I thought I was learning marketing. Mostly I was learning how little I understood about why anyone stops to look at anything.

For a long time I held on to a comforting explanation: people just hadn’t understood the value yet. The nice thing about that explanation is that it asks you to change almost nothing. The product is fine; the message just needs to be clearer. New copy, a better demo, and someone will get it.

Sometimes that’s true. But a lot of the time, people understand perfectly well what you built and simply don’t need it much. From the outside the two look identical. For the person building, they point in opposite directions: one means keep explaining; the other means going back and re-examining the need itself. It took me longer than I’d like to admit to tell them apart.

Eventually I set myself a deadline: if I still couldn’t find an answer, I’d switch projects. There was nothing dramatic about the decision. Engineers are odd this way—as soon as a new problem shows up, attention drifts toward it. The frustration from the old project doesn’t vanish, but something new is always exciting again.

The second project didn’t start well either; I couldn’t even say clearly who it was for. This time I didn’t design a growth strategy in advance. I just kept improving the experience and occasionally wrote about the process online.

What changed my mind wasn’t a well-designed campaign. If anything, it was the opposite. While I was pushing hard, almost nobody came. Later I got busy with other work and left the project alone for a while—and users slowly started arriving anyway.

The growth was nothing to brag about. But it was the first time I could see, concretely, that some growth has little to do with which marketing move you finally got right: there was a need sitting behind the product all along, and the people who genuinely have it don’t need to be educated about why it’s useful.

Since then, my picture of indie development has changed quite a bit, and AI has made the change starker. Code is easier to write now, which means the questions the technical difficulty used to cover up are standing there in the open: does anyone actually care about this problem? How do they cope with it today? Why would they switch? Why does someone say “that’s interesting” and never come back the next day? Those questions are much harder than shipping a feature.

I used to think indie development was a wrestling match with technology. The longer I do it, the more it looks like a wrestling match with my own judgment. It’s easy to overestimate a need because you find the problem interesting; to treat a few kind comments as validation; to treat constant product tweaks as progress; to treat a busy day as movement toward the right answer. And since there is always another feature to build, another page to redesign, another experiment to run, it’s easy to never get around to the simpler, more uncomfortable possibility: maybe this matters less to other people than it does to me.

Another product I worked on later showed me the same thing from a different angle. Much of it is just recording: writing down what happened, what I thought, what state I was in. Once, going back through older entries, I realized I’d been doing badly for a while without noticing. From inside, everything looked fine—there was work every day, problems getting solved, a sense of moving forward. Only from a distance could I see how much my judgment had been bent by that state. It felt a bit like waking from a dream that had lasted too long.

There’s also a rarely discussed difficulty in working alone: almost nobody volunteers to warn you. No manager tells you the direction is off, no colleague questions the assumption in a meeting, no teammate notices you’ve been circling the same problem for weeks. That freedom is a large part of the appeal. Its other side is that every important judgment eventually lands back on you: is this worth another month? Am I persisting, or just unwilling to let go? Am I solving the problem in front of me, or just staying busy because the harder conclusion is uncomfortable?

So the longer I do this, the more I value things that let me look back. Data, a diary, old products, things I wrote, decisions I made. They don’t necessarily tell me what to do next. They show me things that were invisible while I was living them.

People occasionally ask whether starting indie development at 35 is still worth it. I find it hard to give a clean yes or no. It isn’t magical—being technically good doesn’t summon users and revenue, and you can build something elegant and discover almost nobody wants it. But it isn’t merciless either; no door slams shut at a particular age.

Looking back, the most valuable thing these years gave me isn’t a stack of new technologies. It’s slowly being able to tell apart things that used to look identical to me: a need that exists and a need I wish existed; something worth continuing and something I keep going only because I’ve already spent so much on it; what looks like progress and what is only motion; and, once I notice the direction might be wrong, whether I can admit it a little sooner than last time.

If age brings any advantage, I doubt it’s experience in the usual sense. More likely it’s having been wrong enough times to be a bit more careful about where the time goes next.

For independent work, that may matter more than another technology.