Last weekend I sat down with Rork and started jotting down apps I wanted to build. Thirty minutes later, I had twelve ideas on the page. Each one felt like something Rork could get running in a few days, and at first I was genuinely excited. Then I looked at the list and froze.
"If I actually built all twelve, who would maintain them?"
I've been running an indie app business since 2014, and the combined download count crossed 50 million a while ago. The thing twelve years has taught me, more than anything else, is that the building phase is the short part — operating the app is the long part. Rork has dramatically lowered the cost of building. It hasn't lowered the cost of operating. If anything, it's made the danger of overcommitting much sharper, because we can now ship things faster than we can take care of them.
This post is about three questions I now ask myself before I open Rork. They're not rules I claim to follow perfectly. They're the filter I've slowly built over twelve years of saying "yes" to too many ideas and learning to say "later" or "no."
Filter 1: "Will I still want to build this three weeks from now?"
If I went through my notes from the past twelve years, I'd probably find over 150 app ideas I wrote down and never built. The pattern is pretty consistent — the day I wrote them down, the energy was real. Three weeks later, when I reread them, most of them had cooled into something I could let go of without regret.
Rork makes it tempting to skip that three-week cooling window. Because a working prototype can land the same day the idea did, it becomes hard to tell the difference between the energy of an idea and its actual survivability as something you'd run for a decade.
After Rork Max launched, I spent a few weekends building prototypes for new ideas. Monday morning, looking at them with fresh eyes, almost all of them landed in the same place: "this isn't a theme I'd want to live with for ten years."
Now I deliberately give myself at least three weeks between writing an idea down and starting to build it in Rork. If the impulse is still there after three weeks, it's probably moved from enthusiasm into a quieter willingness to commit.
The one sentence I ask myself is always the same:
"Will I still want to reply to a review of this app three years from now?"
If the answer is no, the idea is already off the list — even if Rork could have made it run.
Filter 2: Does this answer "the next wish" of someone already using my apps?
This one comes from running wallpaper and wellness apps since 2014, and especially from how my thinking has shifted in the past year.
If I read reviews for Beautiful HD Wallpapers or Ukiyo-e Wallpapers carefully, users leave more wishes than I used to notice. Lately I've been seeing things like, "I'd like a mode where wallpapers fade in slowly instead of swiping per second," or "I want playlist-style category sequences." Quiet requests that I never would have thought of on my own had been piling up in the margins for a while.
Building an app that answers a wish from an existing user tends to be far more sustainable to operate than building a brand-new app for strangers. That's been my honest twelve-year takeaway. Acquiring brand-new users from zero is expensive for an indie developer like me. With existing users, the relationship — the trust, the goodwill — is already there.
Rork happens to be a great fit for this. The core experience of the original apps is something I spent over a decade refining. What I can ask Rork to help with are the surrounding experiences — a new sister app, a focused secondary mode, a lightweight companion. The core stays in my hands. Rork extends the edges.
The question I ask is:
"Can I already picture a few faces of people who would actually use this?"
If no faces come to mind, the idea goes back into the pile labeled "needs more user research before I build."
Filter 3: Am I genuinely ready to operate this for years?
This is the toughest of the three, and I don't pretend to answer it perfectly every time. But I can't skip it.
Running a single iOS app properly comes with a minimum continuous workload:
- An annual OS update pass (I'm in the middle of supporting new iPhone resolutions across four iOS apps this May)
- AdMob mediation partner management and optimization toggles
- Multilingual review replies (I respond to reviews in 16 languages)
- Same-day responses to whatever Crashlytics surfaces
- StoreKit and AdMob SDK version chasing
Shipping a new app means adding one more app's worth of this ongoing work — permanently. Even if Rork compressed the "building" stage to three days, the next ten years are mine to operate.
Lately, before I start a prototype, I run a quick "operations simulation" in my head:
[Operations simulation questions]
1. Will I still love this theme five years from now?
2. When the SDK upgrades get painful, will I still have the will to do them?
3. Can I picture a user I'd genuinely want to be thanked by?
4. If revenue stayed at zero, would I still have a reason to keep it alive?
5. On top of the four apps I already run, can I actually carve out the operating hours?If any single answer is a clear "no," I don't take the idea past prototype — even if Rork made the prototype look great. This isn't really about courage to not build. It's about subtraction in service of the users I already have.
How the filters change in the Rork era
These three filters aren't new. I held them before Rork existed. What's changed is how much weight each one carries now.
Before Rork, the cost of building was high enough that ideas got naturally filtered just by the friction of starting. Technical difficulty doubled as a quality filter. You didn't have to apply your decision criteria with much discipline — most ideas died from sheer effort.
After Rork, that filter is gone. An idea can become a working app the same day it arrives, which means your internal decision criteria are now the only thing standing between you and an unsustainable portfolio.
That's both liberating and harder than it sounds. When I first taught myself to program back in 1997, my only wish was to be capable of building things. Almost thirty years later, my actual struggle is choosing what not to build. Being technically able to make something, being responsible to ship it, and being committed to operate it are three completely different questions — and Rork has, if anything, made them sharper.
For more on how I think about long-term indie development, you might also enjoy No-Code Tools vs Rork: An Honest Comparison and The New Rules AI Has Forced on Indie Development — What Working With Rork Showed Me.
Quietly, but with intent
My notes still have a few Rork ideas sitting there today. A few of them will fall away in three weeks. A few might survive and end up shipping six months from now. The ones that survive, I'll trust quietly.
Rork makes it feel like you can build anything. And because of that, what you choose not to build is becoming the thing that defines the quality of your work as an indie developer. I'm still finding my own footing in this new kind of freedom, trying to pick the apps I'd want to live with for the next decade. If you're navigating the same question, I hope something here is useful as you find your own filter.