I’ve been a solo developer for a long time. Long enough to know that the hardest decision before a launch isn’t technical — it’s this one: do I ship now, or do I wait until it’s more complete?
I faced it again with Newsairy, my new RSS reader for iPhone, iPad, and Mac. And I chose to ship early. Ten days in, I’m glad I did — but not for the reasons I expected.
The Temptation to Wait
My mental list of “things Newsairy should have before launch” was long: sync with more aggregators, more customisation options, a few more UI refinements. Every item felt reasonable. Taken together, they added up to weeks — and for a side project built in spare time, weeks have a way of becoming months.
The argument for waiting is compelling because it’s not irrational. You want your app to make a good first impression. You worry that a one-star review for a missing feature will follow you forever. You have a clear vision of what the product should be, and it doesn’t quite match what you have today.
Why I Shipped Anyway
I launched Newsairy with what I’d call a solid, stable core. It does what it promises, but there were things it didn’t yet do, features I had planned and simply hadn’t built yet.
Building in a vacuum is a risk. The longer you wait, the more time you invest in assumptions nobody has validated. A feature that feels essential to you might be irrelevant to your users. A feature you consider secondary might turn out to be the thing people ask for first. You don’t know until real users tell you — and they can only tell you if there’s something to use.
There’s also timing. New apps ship every day, and the problem I’m solving is one others feel — which means others are building for it too. I’d rather be in the market and learning than still preparing while someone else ships first.
You Are Not Your User
I went into the launch with a roadmap. Features I’d planned, prioritised, and in some cases already started building. I expected users to ask for the things on that list. Some did. But the pattern wasn’t what I anticipated.
Several features I thought were important? Almost nobody mentioned them. Things I’d spent time thinking about, designing in my head, assuming were on everyone’s wishlist — silence. That’s not a complaint, it’s information. It means I would have spent weeks building something that wouldn’t have moved the needle for a single user.
Features I hadn’t prioritised — or hadn’t even considered important — came up immediately. The clearest example: “Mark all as read.” It’s a common feature in RSS readers. I knew it existed. I just don’t use it myself — I have a different way of managing my feeds, so the absence never registered as a gap. Within the first few days, at least three different users asked for it. Three separate people, unprompted, in different conversations. It’s now going into 1.04.0.
That’s the kind of signal you simply cannot get before launch.
The reason is straightforward: as the developer, you use your own app in a particular way. Your habits, your workflow, your mental model of what the app is for — all of it shapes what you build and what you overlook. The features that feel obvious to you are the ones that match your own usage. The features that feel optional are often the ones you don’t use.
I had conversations on Reddit and Mastodon with people testing Newsairy or comparing it to other readers. When someone asked how it compared to another app, my first instinct was to think about what it offered more. It took me a few conversations to realise they were asking something different: is the one thing I love about my current reader even in your app?
The Roadmap Is Now a Conversation
Before launch, a roadmap is a monologue. You decide what’s important, you sequence it, you build it. It’s your best guess about what users want. It might be a good guess. It’s still a guess.
After launch, the roadmap becomes a conversation. Features get moved up because three people asked for the same thing in a week. Other features get quietly deprioritised because nobody mentioned them. The sequence starts to reflect actual user needs rather than developer assumptions.
That said, none of this works without a few conditions. The foundation has to be solid: few features, but working. “Ship early” doesn’t mean unfinished or broken — if the core experience is buggy or confusing, early feedback will be noise. You need to be able to act on what you hear, which means short release cycles. And you need channels to listen. Reddit and Mastodon worked well for me.
I also ran a beta before launch — 60 to 70 downloads, two pieces of feedback. Maybe I promoted it in the wrong places. But it was a reminder that access to the app doesn’t automatically translate into signal. People need a reason to engage, and “it’s a beta, please test it” is rarely enough on its own.
Ten Days Is Not a Conclusion
I’m not writing this as a success story. Ten days is too short to draw conclusions about the app, the market, or whether early shipping was the right call in any definitive sense.
What I can say is this: I already know more about what my users need than I did before launch. Several things I assumed were important turned out not to be. Several things I’d overlooked are now on the short list. The roadmap looks different than it did two weeks ago, and it looks better.
If you’re sitting on an app that’s mostly done, wondering whether to keep adding before you ship — I’d encourage you to think carefully about what you’re waiting for. You can’t know what your users want until they’re actually using your app. Ship something solid, and they’ll give you the roadmap.