We stopped forcing the subscription model on our users. Here is what happened.

How and why Lovable introduced ‘top-up’-style monetization.

Is there anything that VCs, boards, or business leaders love more than recurring revenue? If so, I haven’t found it.

And so the “subscription economy” has exploded in the last decade - and it’s the backbone of the SaaS. And let’s be real, much of the Growth and Marketing discipline has been built around learning how to create and optimize a model around Annual Recurring Revenue (ARR)... aka, those sweet, sweet subscriptions.

But (and I know some of you don’t want to hear it)... not every business should monetize through subscriptions. In fact, most of the time it doesn’t even make sense. And your customers may hate you for it.

That’s something a lot of AI companies are realizing right now. We did at Lovable.

---

AI companies need business models as innovative as their products. Fast.

Stripe Billing helps teams like OpenAI, Anthropic, and Lovable launch and scale without building billing from scratch.

• Usage, hybrid, credits, flat + overages

• Higher revenue, less churn

• No-code + modular APIs

• 100+ payment methods, 135+ currencies

Don’t let billing be the bottleneck.

→ Get the playbook for scaling AI

---

Let’s look at Lovable. Our subscription model is simple: freemium by default with 5 daily credits to build, and if you need more credits or features, you upgrade to a paid plan. If you’re on a building streak, you can keep upgrading to get the credits you need. If demand drops off, you downgrade.

Now, from a business perspective: This is great. It’s driving that sexy sexy ARR, which investors love and everyone drools over. It’s recurring! It’s predictable! Who doesn’t want a steady stream of income?

So, that’s how we’ve operated since launching, but a couple things changed:

1. Our customers yelled at us. People were not happy with the subscription-only option. Mentally, signing up for a subscription felt like a commitment. Upgrading and downgrading felt permanent. They were very unhappy about us not having more flexibility with credits.

2. We looked at how people were engaging with the product. Turns out, the usage trends didn’t always support this subscription-type billing. Nobody predictably comes in and spends 100 credits every month, month after month. Generally, they come in when creativity strikes, when there’s something they need to build. Very few people are on a consistent track, so the usage trends are super irregular.

So… what do we do?

Understandably, this was a major cause for concern, internally. We’re young and willing to take big bets… but would making changes to the model hurt our ARR? That’s what everyone judges us by! The existing structure was also a key factor in our strong upgrade rate, especially in the first month - people start using the product, they like it, and they realize they need more, so they upgrade. There’s a huge downgrade rate afterwards, but a lot of them do stay on the higher upgrade. Would adjusting the subscription-only system hurt that? If we introduced a different system, would we cannibalize our recurring revenue? Would we be in the negative?

But we knew we needed to do something. Our users kept hammering us: They refused to upgrade and many even told us they were leaving the product to go to a competitor that offered more flexible billing. ‘If this is how you’re going to force me to transact with you, I’m out.’ The negative feedback was starting to pile up. We could tell we were creating a not-lovable experience.

Ask the audience: Top-ups vs. Overages

First, I started with polling on Linkedin. The key question was - how do we approach this? Do we allow subscriptions to go into overages, and then you can pay for overages as a one-off? Do we actually offer top-ups? Is there some other method?

And this is the beauty of building in public, because… the people spoke! I got hundreds of comments with lots of very detailed feedback. And since there was a poll, the winner was clear: People wanted add-ons, not overages.

How do we price the add-ons? Time to do some testing.

We wanted to run this as an A/B test to make sure there would be a positive impact on the user experience while optimizing business impact. Our next question was: If we’re going to do credit top-ups (which is what we decided to call the add-ons), how do we price it? These top-ups would certainly never be priced lower than subscriptions. That would not make sense. But… do we:

(a) Charge the same for top-up credits as subscription credits, or
(b) Charge a slight premium on the top-up credits, anchoring into a ‘subscribe and save’ mentality.

To me, this second option was like Amazon’s ‘Subscribe & Save’ system. Pay full price, or get a percentage off if you subscribe. Very popular and widely understood.

For our first test cell, we priced top-ups exactly the same as subscriptions. Our current price is $0.25, so this meant you could buy 100 credits for $25. This meant there was no difference in how you purchased your credits.

This approach led to a significant improvement in engagement. But the overall money that we collected was significantly down. So, this didn’t really make sense from an overall monetization perspective, but given the change in engagement, we learned an important lesson: Our subscription model was holding our engagement back.

This matters in any company, but it’s particularly important for us: As I recently shared, our new North Star Metric for the year is daily active apps. And the subscription model was preventing us from getting more engaged builders.

So, our other two test cells looked at how much to charge above the baseline subscription rate for credits. We were looking at two options, 20% higher and 40% higher. Again, our credits are valued at $0.25 in the original subscription-based system, so the 20% increase meant $30 for 100 more credits and the 40% increase meant $35 for 100 more credits. The message was very clear: Buy these ‘packs’ of credits (top-ups) or subscribe-and-save, either at 20% or 40% discount, depending on which test the user saw.

Sidenote: Having the right tech stack was crucial for this. Part of the reason I’m excited for Stripe Billing to sponsor this post is because they were a key part of our success. Trying to implement this kind of more complex billing system would have been a mess without them. Here’s our announcement, with some more details.

We kicked this off and waited a few weeks to see the results come in.

Goldilocks, FTW

These were the results:

• A 20% markup won across the board. Engagement increased, bookings increased, and while paid to higher paid plan upgrades dipped nearly by half, paid retention improved enough to offset the impact.

• The 40% premium, though, was too expensive. Engagement didn’t go up and the top-ups take rate was too low. It was simply the wrong price point.

This made the conversation easier: Even though giving an alternate path to pay would reduce our paid upgrades, we’d get upside via improved retention and increased engagement in the long term.

I’ve been surprised at how quickly this has been adopted - already, just one week in, 20%+ of our bookings are through top-ups! Aaand our subscription revenue is still growing.

But the real key is the impact on product usage. This change is positively influencing our crucial North Star metric by increasing engagement.

And it’s also increasing retention. Retention for our paid plans has improved by 7%! This means that people who are buying top-ups are actually staying on their plans for longer because of that option, as opposed to doing this upgrade-downgrade dance, which we considered to be easy, but obviously wasn’t easy enough.

And most importantly, the group that is buying top-ups are far more engaged with the product. They send more messages. They publish more. So, these are not some kind of second-class citizens within our usage base. These are actually our best users that want to transact with us in this way.

And, again, because this was such a major request from our community, we got a lot of love when we finally released this.

Trapping your users in a subscription model is never worth it.

My biggest takeaway from all of this: If you just optimize for ARR, you’re only thinking in the short-term. If the subscription model is misaligned with actual user behaviors, you’re in trouble. And fortunately, there are ways to create flexibility to accommodate the customer.

And I want to be clear: We found that price point that works best for our users and for us, and that’s what we went with. This is not about over-optimizing your subscription model, to squeeze out every last penny. If you try to protect every dollar of your ARR and offer a sort of second-class option for more credits that is super expensive, you’re going to create a mess. “Subscribe and save” is a legit, commonly understood concept, so you can work with that. If you’ve got a subscription model right now, it may be worth considering whether a pay-as-you-go option fits in.

---

Edited by Jonathan Yagel.

---