Why I ditched monthly pricing
Ruby Native isn't a traditional SaaS. So it shouldn't be priced like one.
When I first announced Ruby Native, I priced it like every other SaaS tool I’d ever built: monthly subscriptions at three different tiers, renewable forever.
It felt right! And it’s what developers expect. It’s the “proven” model.
Then I sat down and asked myself an uncomfortable question: What do customers actually get from Ruby Native month after month?
And I didn’t love the answer.
The problem with monthly recurring value
Ruby Native lets Rails developers ship native iOS apps without leaving Ruby. The pitch is: write Ruby, get a native app.
Here’s the thing about that native app once it’s in the App Store: most of it is your Rails app rendered in a web view. You push a change to your server, the mobile app picks it up automatically. No rebuild or App Store review. And Ruby Native isn’t involved at all.
So what does month three of a Ruby Native subscription actually buy you? Or month six? If your app is shipped and working, the answer is: not much. You’re not building on Ruby Native’s infrastructure. You’re building on yours.
That’s a rough foundation for a monthly subscription business. You’re essentially charging people a recurring fee for a tool they used intensively for a few weeks and now barely touch.
I could have glossed over this with more features and more integrations. More more more! In the age of agentic coding… that feels possible. Right?
But I’m a solo operator. I’d rather be honest about what the product actually delivers than manufacture reasons for monthly churn anxiety.
What changes when you switch to annual licensing
The new model flips the equation to match reality:
Repo access is yours forever once you’ve held an active license. Ship the app, let the subscription lapse. The code you built on doesn’t disappear.
Cloud builds and iOS compatibility updates require an active subscription. Apple changes things constantly. New Xcode versions, new SDK requirements, new App Store rules. Staying current is ongoing work, and that’s what an active license covers.
Your app stays in the App Store even if your subscription expires. You just have to build and deploy manually instead of using Ruby Native’s cloud infrastructure.
This maps to actual value. Paying while you’re actively building or need to stay iOS-current makes sense. Paying because you forgot to cancel doesn’t.
The tiers
I settled on just two tiers, priced annually:
STARTER at $299/year: Cloud builds, repo access, email support. For developers who want to ship and stay current without hand-holding.
PRO at $999/year: Adds in-app purchases and priority support. For apps that need to make money.
I also dropped MAU limits entirely. Usage caps on a product that runs on your infrastructure never made sense anyway. It was legacy SaaS thinking applied to a tool that doesn’t work like SaaS.
The trade-off I made
Annual licensing means lower theoretical LTV than monthly if a customer sticks around for years. I’m aware of that.
But monthly pricing for a product with thin recurring value creates a different problem: customers who feel vaguely guilty every month, who churn when they get busy, who resent the charge when they’re not actively building. That’s a bad relationship to be in.
Annual licensing sets honest expectations. You pay for a year, you get a year of cloud builds and iOS updates. If that’s worth it, renew. If not, your app still works. And there’s no lock in if you want to use the code as a starting point.
I’d rather charge a fair price for what I actually deliver than optimize for a revenue model that doesn’t fit the product.