Choosing a Freemium Model

October 12, 2025 • By haveibeenexpired team • 7 min read

TL;DR: haveibeenexpired now has free and paid tiers. Existing users are on the free tier. Good news: unlimited hosts, unlimited automatic discovery, all webhooks still work, and you'll never miss an expiring certificate. The trade-off: checks happen adaptively (up to 2 weeks apart for healthy certs, accelerating as expiration nears), so dashboard data may be stale and notifications may arrive late. Pro users get continuous real-time monitoring!

Introducing Free vs Paid Tiers

I started haveibeenexpired based on personal (and painful) experience. My goal was to play around with something useful for others, and run my own side project. Over the past 4.5 years, with long pauses from my side, the app has grown nicely. It now serves over 1,300 users, scans 2,000+ domains, and monitors more than 140,000 hosts for SSL certificate expirations.

This growth put some strain on the app's basic infrastructure, and began degrading service to its users. At first, every monitored host was checked once every couple of minutes. Today, hosts can go hours or even days between consecutive checks. This can easily result in late notifications! This slow reduction in value prompted me to take action I'd been considering for a long time. Instead of spending a few more dollars on infrastructure to speed things up, I decided to take a product-driven step forward, and introduce a split between free and paid functionality in the app.

This step sent me down a rabbit hole of investigating what the app's users really care about. I developed a hypothesis that might help the app pay for itself - while ensuring free-tier users get consistent, reliable value from the app.

This post describes the analysis I made, the product mindset I applied, and also - what should you, as an existing user of the app, expect from this change in either case - whether you decide to stay on the free tier, or to upgrade to the paid subscription.

The Freemium Decision: What to Limit?

There's plenty of prior art in the world of SaaS when it comes to freemium models. You choose what to limit for the freemium users, and see who pulls out their credit card to get the feature you gated. In reality, this can be a very thoughtful exercise in understanding your target audience, and what they get out of the app.

There is also the need to strike a fine balance - keep the non-paying users happy enough to keep using the app, while creating some clear friction that will help the right users self-select to upgrade. In other words: annoy the free tier users too much, and you won't have any (let alone paying users); go overboard with the free tier users, and no-one has a reason to upgrade.

I started with deciding on the paid tier - I actually want it to provide the exact same experience that the app's users are having today. In other words, I don't know about anything sufficiently probable that (a) doesn't exist today, and (b) would be worthwhile for the users to pay for. I only know what some users have found more compelling about the app, and even that is anecdotal at best.

This means that the free tier will need to limit something that the app does today. The goal is to free up resources to frequently monitor the domains and hosts of paying users. I went over the immediate suspects such as limiting the amount of hosts that can be monitored for a free account, or limiting the amount of checks per day. Any such approach seemed unfair towards the free tier users, basically pulling the rug underneath them - going from a completely reliable monitoring app to one that could silently let a certificate expire, only to say 'if only you had paid, you would have known in advance'. This could kill the app through negative word-of-mouth, contrasting with the positive referrals I am now getting.

Another consideration was to limit the automatic detection of new hosts by monitoring a whole domain. I rejected this, as it is what my users find most compelling about the app - the 'set it and forget it' mode that doesn't rely on the user to update their account with what they want to monitor, and keeps it always up to date.

I then considered what actually triggered this change: the creeping delay in notifications which got me thinking of giving paying users the real-time experience all users have had when the app just started. Instead of letting the growth of users and host impair the experience for everyone, I want to find a way to minimize the adverse impact on the free tier users, while guaranteeing real-time monitoring for paying users. The adverse impact itself is the differentiator! I just need to find a way to control it. The question then becomes very focused - for free tier users, how infrequently can the app check the hosts, while still meeting user expectations by notifying in reasonable time?

I didn't foresee all the aspects of the app where users will need to be informed of the free tier limitation. Going through every view, notification and report revealed more and more opportunities to communicate with the users. If ignored, users would lose trust with the app ("why did this notification arrive now, when I asked to have it sooner?"). If handled too bluntly, it could push users away ("stop trying to upsell me all the time!"). The changes to the app are exactly what the next section is about.

What This Means for You (Existing Users)

You're on the free tier now—and nothing breaks:

All your hosts continue being monitored (unlimited, as always)
Automatic host discovery keeps working (unlimited, as always)
All your webhook integrations keep working (unlimited, as always)
You'll always be notified in time to prevent a certificate expiration

What changes: Check frequency and data freshness

Checks now happen adaptively (up to 2 weeks apart when certs are healthy)
Checks accelerate automatically as expiration approaches (daily, then hourly)
Dashboard data may be hours to days stale (instead of real-time)

What you'll notice in the app:

Dashboard & hosts pages: For free tier users, the "Last checked" column now shows "Next Update" to show when the host gets checked next. This will be no more than half the time remaining for the certificate expiration, capped at 14 days.
Weekly email reports: For the free tier, a "Last Updated" column now appears in the list of upcoming expirations. This shows any staleness in the data.
Expiration notifications: For the free tier, a "Threshold crossed" field shows when the expiration threshold was actually crossed. As per the adaptive check scheduling, this may be between 0 and 14 days prior to the notification being sent, but never more than half the period of the threshold itself (i.e. no more than 2 weeks late for 4 weeks threshold, 1 week late for 2 weeks threshold, 3.5 days late for 1 week threshold, etc.)
Update notifications: For the free tier, a "Update occurred" field is added as a time period in which the update took place. This period will reflect the time between the last check when the previous cert was observed, and the first check when the new cert was detected, resulting in windows of up to 14 days at most.

Pro tier users will not see any of these changes, as their experience will be based on continuous, real-time monitoring, incurring no delays between events (such as crossing a notification threshold) and the notification itself. Data freshness will be maximal, delayed by a couple of minutes at most.

Why this still works for most users:

The adaptive check interval accelerates as expiration approaches - checks become more frequent when it matters most
Certificates have fixed expiration dates, so the system can schedule checks strategically around those dates
The system never skips checks - it may delay them, but every threshold gets checked and every notification arrives

Why This Model Works

Looking back at the decision-making process, I believe this approach strikes the right balance for both user segments and for the app's sustainability.

Free tier users get real value:

The free tier isn't a demo or a teaser - it's a fully functional monitoring service. You get unlimited automatic host discovery, meaning every certificate you deploy gets tracked without you lifting a finger. You get reliable expiration notifications - they may arrive with some delay, but they're never skipped. There are zero limits on how many hosts you can monitor, zero anxiety about hitting caps or quotas. For personal projects, side hustles, and small teams where a day or two of lag doesn't impact operations, this is perfect. You're still getting the core value proposition of the app: never letting a certificate expire because you forgot about it.

Pro users get clear premium value:

For production environments and business-critical infrastructure, the pro tier delivers what you need: near-real-time visibility. Your dashboard is always current. When a certificate changes unexpectedly, you know within minutes, not days. Notifications arrive immediately when thresholds are crossed. When downtime means lost revenue or customer trust, this responsiveness is worth paying for. The key difference: you're not paying to unlock basic features that should have been available all along. You're paying for responsiveness - for the operational certainty that comes from real-time monitoring.

Why it's fair:

This model feels honest because the pricing reflects actual resource costs. More frequent checks mean more infrastructure to run. The free tier's adaptive scheduling allows the app to serve many users sustainably, while paying users subsidize the system that benefits everyone. There are no artificial walls, no "gotcha" moments where you suddenly hit a limit that forces an upgrade. The free tier can exist generously without guilt or pressure tactics. And crucially, the premium tier feels like premium service - better responsiveness, better timeliness - not like you're being held hostage for features that were arbitrarily locked away.

The result: A business model that scales while respecting users at every level. Free tier users aren't treated as second-class citizens waiting to be converted. Pro users aren't paying for basic functionality. And the app can grow sustainably without compromising on the values that made it useful in the first place.

Want real-time monitoring for your production infrastructure? Upgrade to Pro for continuous checks and immediate notifications.