What Shipping 5 Apps Actually Taught Me About Finishing Things

I have five apps in the App Store. When I tell people that, they usually ask what the combined revenue is, or which one took off. The honest answer to both questions is: not much, and none of them. But that framing misses something I think is more interesting.

Each of those five apps taught me something I could not have learned any other way. Not from a course, not from reading other people’s postmortems, not from thinking about it. You only learn certain things by going all the way through the process, including the parts that feel pointless.

Here is what I actually learned.

Finishing the first one is the only thing that matters

My first shipped app was Rise and Rattle, a Snakes and Ladders game built in Flutter. By most measures, it is the simplest thing I have ever made. The game logic is not complicated, the graphics are flat, the monetization is nonexistent. But it took me longer to finish than I expected, and almost didn’t ship.

Not because of any technical problem. Because I kept finding things that felt not quite right. The board animation was slightly off. The color palette needed one more pass. The icon did not feel like an icon yet.

None of it actually mattered. What mattered was that I had never put something on the App Store before, and I was using taste as a reason to avoid the part that scared me, which was publishing. Making it available to strangers. Committing to it being real.

I shipped it anyway, with the imperfect animation and the icon I wasn’t fully happy with. And the moment it went live, something shifted. The fear of publishing became a known quantity. I had done it once, which meant I could do it again.

Everything after that was faster, not because I got better at building, but because I stopped treating the finish line as something to approach carefully.

Each app had a different reason it almost didn’t happen

Steepr, my tea timer for iPhone and Apple Watch, almost didn’t ship because I spent three weeks on the Watch complication. A complication is the small data element that appears on the watch face. Most users will never configure one. It is genuinely a peripheral feature. But I had decided it needed to exist, and I could not let go of it until it worked exactly the way I wanted.

Patterns, the OCD journaling app, almost didn’t ship because I second-guessed the entire premise halfway through. Who was I to build something for people managing a mental health condition? Did I have the right to put my name on this? I rewrote the app description six times trying to find language that felt appropriate.

Splashy Sketchpad, my infinite whiteboard for macOS, almost didn’t ship because macOS development was new territory for me and I hit a rendering performance problem I didn’t know how to solve. I spent two weeks debugging it, got close enough to acceptable, and shipped it.

Lofikofi, the focus timer, almost didn’t ship because I got bored of it. I’d been working on it for a while and the novelty was gone. The app still needed work but my motivation was near zero. I shipped it to get it out of my head.

The reason it almost doesn’t happen is always different. But there is always a reason, and the pattern I eventually noticed is that none of the reasons were actually about the app. They were all about me. My fear, my doubt, my distraction. The app was fine. I was the problem.

Quality is a moving target that will eat you alive if you let it

There is a version of quality-consciousness that is genuinely useful. Caring about animation curves, typography, the way a button feels when you press it. That kind of attention compounds over time and shows up in work that feels considered rather than assembled.

There is another version that is just perfectionism wearing a respectable name. The difference is whether your quality bar is moving toward something or just moving.

I had to learn to ask, for each thing I was unhappy with: will this matter to someone using the app, or does it only matter to me because I made it and I can see the seam? Most of the time, the honest answer was that only I could see the seam. The seam was invisible to everyone else.

Shipping something that is 85% of what you wanted it to be is almost always better than shipping nothing while you chase the remaining 15%. The 15% will still be there after you ship. You can update. The App Store has a review process, not a one-strike policy.

The app you think will do well is almost never the one that connects

Before each launch I had a private prediction about which app would find an audience. I was wrong every time.

Rise and Rattle, the game I made mostly as a learning exercise, has a small but consistent review streak from families who play it together. Steepr gets messages from tea enthusiasts who say it changed their routine. Patterns gets the quietest messages, from people who are clearly going through something difficult, and those messages are the ones that stay with me.

None of these were the responses I predicted. None of the apps found the audience I imagined. They found a different one, or a smaller one, or a more specific one. This is something you cannot reason your way to in advance. You have to ship and then listen.

The fifth app is easier than the first, but not for the reason you think

By the time I shipped Lofikofi, I had a setup. I knew roughly how long things took. I knew which parts of App Store Connect would be annoying. I had screenshots templates. I knew what my icon review process looked like.

But the practical efficiency was not the real change. The real change was that I had stopped attaching my self-worth to the outcome. The first app felt like a verdict. If it flopped, it meant something about me. By the fifth, a quiet launch was just a quiet launch. Some things find their people quickly, some things don’t, and neither outcome tells you whether you should keep building.

That detachment is probably the most useful thing I own now. It lets me start things that might not work, which is the only way to eventually make something that does.

The lesson underneath all of it is simpler than any framework: finish things. Not because finishing guarantees anything, but because you cannot learn what comes after finishing if you never get there.