The Shipaton sprint didn’t go as planned—but it taught me more about sustainable indie development than any successful sprint ever could. Some lessons you just have to experience yourself to believe them. This was one of those times.

💡 This post accompanies Episode 5 on YouTube, where I walk through the full story with behind-the-scenes footage.

The Context: Way More Than Just an App

Before I dive into the Shipaton itself, I need to set the scene. Because I didn’t just start building Paw Trail—I started it in the middle of massive personal changes.

I left my full-time job to become an indie developer. I relocated to a new city. I helped my mother move to Madeira. All of this took a huge amount of time, and I underestimated it by a lot.

So when the Shipaton was announced, I was hyped. I wanted to participate, I wanted to ship something, and I settled on the first idea I had just to get moving fast.


The Plan: First Place, Obviously

My plan for Paw Trail was clean and ambitious:

  1. Ship v1 as early as possible—a simple iOS18 version
  2. Ship some updates, get feedback, iterate
  3. Drop a big update on iOS26 release day with the new Liquid Glass design
  4. Record a high-quality submission video
  5. Win first place in the Shipaton

Simple, right?

And all of this paired with a weekly YouTube series and regular social media posts documenting the journey.

Clean. Achievable. First place, obviously.

Or so I thought.


Finding #1: Do Market Research Before You Build

After I built v1, I decided to check the App Store keywords I was targeting. And I discovered that the keywords had nearly no popularity.

That was my first finding: ==You must do the market research before you build.==

Building is fun. Selling a great product to an empty market is the pinnacle of not fun.

App Store Connect keywords show low search volume
App Store Connect keywords show low search volume

The moment I realized my target keywords had minimal search volume


The Spiral: Feature Creep Takes Over

Discovering the empty market triggered something in me. A huge feature creep.

A simple walking tracker for dogs was becoming a huge undertaking. I developed:

  • Route planning
  • Route publishing
  • Route navigation—all integrated with current weather reports and weather alerts

I created scripts that imported nearly all free available trails on the internet and imported them into the app. Paw Trail was getting huge.

But ==huge does not mean good.==


The Breaking Point: Pulling the Plug

Some days before the iOS26 release, I had to pull the plug.

Route publishing and route navigation were not ready. Some of the imported routes had such low quality that I would have had to develop an algorithm to find the outliers—but that was not possible in such a short amount of time.

That was my second and third finding:

Finding #2: ==Feature creep will kill your progress.==

Finding #3: ==Some features are way too big to do them ad hoc on your own, where others have multiple teams.==

For some problems, the edge cases will kill you—even if the plain feature is easy to moderate to implement.

The edge case trap

In-app purchases are the best example. They are easier than ever to implement, but when you start, you see why a tool like RevenueCat makes so much sense. The edge cases and tiny little features which are just nice to have need so much work.

Life Happened: NSSpain and Getting Sick

So back to the app. At that point, I had to unwire the work of some weeks. And then personal life got in the way.

I went to NSSpain—which was an absolute blessing, by the way. I met incredible people, learned so much, and came back energized.

But then I was hit with COVID. I got sick. I didn’t have the energy to rebuild the app to a state I was proud of, and I also had no time for a good submission video. So I made the decision to pull the plug.


So I Must Be Really Sad, Right?

But I’m not.

In the end, the Shipaton was about shipping. And I did ship.

And I also had really great learnings. Some things you have to experience yourself so that you can believe them.

Paw Trail is live on the App Store. It’s not the version I planned to submit, but it’s real, and I can build on it at a sustainable pace.


Thank You, RevenueCat

And like I made my learnings, others have made theirs too. So I want to thank RevenueCat for creating the desire with the Shipaton for people to start creating—and by that, making progress both in business and in personal life.

I scrolled through the Shipaton app gallery and also tried out many apps during the build-in-public phase, and I was amazed by all the nice apps.

So at the end, I wish all the participants the best of luck for some of the prizes. And I hope that next year there will be a new Shipaton.


Key Takeaways

If you’re building your own indie app or considering joining a future Shipaton, here’s what I’d tell you:

  • Do market research first — Check App Store keywords and validate demand before you write a single line of code
  • Ship the smallest version — Feature creep is your biggest enemy; define the absolute minimum and ship that
  • Build in buffer time — Life happens; account for it in your timeline
  • Some features need teams — Don’t underestimate the complexity of edge cases, even for “simple” features
  • Shipping is winning — Even if you don’t finish what you planned, shipping something real is a victory
💡 Final thought: ==Some lessons you have to experience yourself to believe them.==

What’s Next

I’m continuing to develop Paw Trail at a sustainable pace, focusing on features that actually matter to users. And I’m documenting the journey on YouTube and here on the blog.

If you’re on a similar journey—learning to ship, fighting feature creep, or figuring out how to balance ambition with reality—I’d love to hear about it. Drop a comment on the YouTube video or reach out on X/Twitter.

Thanks for reading. I’ll see you in the next one.