To get customers to upgrade without nagging them, stop asking everyone and start watching for the moment someone actually needs more. Look at the customers who already upgraded and note what they did in the two weeks before: hit a limit, added a second location, connected an integration, ran out of storage. Put your plan boundaries on those things, warn people before they hit a wall, and show the upgrade right where the need appears, with the price and what changes. When a signal fires on a good account, send a short personal email. Then measure upgrades per signal and how many people downgrade again, because a pushy upgrade usually comes back as a downgrade or a cancellation.
This guide is for indie SaaS founders with roughly 30 to 300 paying customers on two or three plans who earn almost nothing from upgrades today. The worked example company, its founder and all of its numbers are made up for illustration. The metric definitions and billing behaviour are from real, linked sources.
Why do upgrades matter so much for a small SaaS?
Because an upgrade is revenue you don't have to find. The customer already trusts you, pays you and keeps their data in your product. For a solo founder, that is the cheapest growth there is.
The metric that captures this is net revenue retention, or NRR. ChartMogul's explanation of net revenue retention defines it as the recurring revenue you have today from a group of customers divided by the revenue the same group paid a year ago, after expansion, contraction and churn. In plain words: if you never signed another customer, would the people you already have be paying you more or less?
A tiny worked calculation, with made-up numbers:
Customers who were paying a year ago brought in $3,000 a month.
Some upgraded since then: +$300 a month (that is expansion revenue).
Some moved to a cheaper plan: -$60 a month (contraction).
Some cancelled: -$240 a month (churn).
NRR = (3,000 + 300 - 60 - 240) / 3,000 = 100%.
At 100%, upgrades exactly cover what you lose, so every new customer is real growth. Without the $300 from upgrades, the same business would sit at 90% and need new signups just to stand still.
Which customers are about to need a bigger plan?
Your best clue is the people who already upgraded on their own. They show you what "needing more" looks like in your product. Skip this and you end up pitching the higher plan to people who will never need it.
How do you pull this data in an afternoon?
List every customer who moved to a higher plan in the last 6 to 12 months, with the upgrade date. A billing export is enough.
For each one, pull what they did in the 14 days before the upgrade from your own database or event log: usage against limits, new integrations, teammates invited, exports, support messages.
Put it in one spreadsheet: one row per upgrade, one yes/no column per behaviour. Add a random sample of customers who did not upgrade, over a comparable 14-day window.
Look for behaviours that show up often in the first group and rarely in the second. Those are your upgrade signals.
In SQL this is usually a join between subscription changes and your events or usage table, filtered to the 14 days before each upgrade. With only twenty upgrades, read them one by one; a careful look at each account beats statistics at this size.
Common signal families:
Product type | Common upgrade signal | What it usually means |
|---|---|---|
Booking or scheduling tool | Monthly bookings near the plan cap; a second location or calendar | The business behind the account is growing |
Email or newsletter tool | List size close to the next tier; sending more often | Audience is growing; email has become important to them |
File, media or storage product | Storage past 80%; larger uploads | They now keep real work in your product |
Analytics or monitoring | More sites or projects; asking about longer history | They rely on the data for decisions |
Developer tool or API | Request volume rising; hitting rate limits; a second project | Your product is in their production path |
Collaboration tool | Inviting a teammate; sharing outside the account | Use is spreading beyond one person |
Write down your top two or three.
Where should the line between plans sit?
Put plan boundaries on the thing that grows when the customer's value grows. Pricing people call this a value metric: the unit that goes up when your product does more for someone, like bookings, contacts or projects. If your signals and your limits point at different things, customers hit walls that feel random.
Never put these behind a higher plan; gating them feels like a ransom:
Exporting their own data. Gating it makes people feel trapped, and trapped customers leave when they can.
Security basics such as two-factor authentication and a password reset that works.
Deleting their account or cancelling.
Bug fixes and basic support for something that is broken.
Anything they already use today. Moving an existing feature to a higher plan is a price increase in disguise.
If your real problem is that every plan is underpriced, that is a different job, and it deserves its own careful plan for raising prices on existing SaaS customers without a backlash. This guide assumes your prices are roughly fine and the issue is that nobody moves between plans.
How do you handle usage limits without breaking someone's work?
The quickest way to make an upgrade feel like a shakedown is a hard wall in the middle of a task. They might upgrade that day, but they will remember how it felt. A softer pattern costs you very little:
Warn at about 80%. Tell them in the product, and by email if they rarely log in, while there is still room to decide calmly.
Allow a grace overage. Let them go a little past the limit until the period ends, such as 10%, and say so plainly.
Never break live workflows. Existing bookings run, scheduled emails send, public pages stay up. Block new additions at most.
Copy you can borrow
These use the made-up plans from the example later in this guide; swap in your own.
Limit banner (in the product, at 80%): "You've used 120 of your 150 bookings this month. Your existing bookings are safe. If you go over, you can keep taking bookings until the end of the month. Studio plan: unlimited bookings for $49 a month. See what changes."
Locked-feature preview (when someone clicks a higher-plan feature): "Waitlists are part of the Studio plan. When a class is full, people join a waitlist and get an email if a spot opens. You can try it free for 7 days, and nothing changes on your bill unless you choose to upgrade."
"On track to exceed" email (sent once, mid-month): "Quick heads-up: at your current pace you'll pass your 150 bookings around the 24th. Nothing will stop working. If this is a busy month, you can ignore this. If it's the new normal, the Studio plan removes the limit. Reply if you want help deciding."
Each one names the benefit, shows the real price, says what stays safe and leaves the decision with the customer.
Where should upgrade prompts appear in the product?
Show the upgrade at the point of need, not on a timer: the bookings page when they near the cap, the settings page when they look for the integration, the share dialog when they try to invite someone.
A good in-product upgrade moment has four parts:
The specific benefit in their terms ("take bookings past 150 this month"), not a generic "Go Pro".
The price and the billing period, visible before they click.
One click to upgrade, with a short line on how the bill changes ("you'll pay the difference for the rest of this month").
A way to try it. A short trial of the single feature, or a reverse trial where new accounts start with the higher plan for a limited time and then drop to the plan they chose, so they already know what they would miss.
Frequency rules that keep prompts from becoming nagging
The Nielsen Norman Group's guidance on when to use modal dialogs points out that modals interrupt people and can make them lose track of what they were doing. Upgrade popups are the worst version of that. A few house rules:
No upgrade modal on login. Ever.
No more than one upgrade prompt per session, and only when a signal is present.
If someone dismisses a prompt, hide that prompt for a set time, such as 30 days.
Never place a prompt over a form they are filling in or a task they are finishing.
Free users with no signals see a quiet link to plans, not repeated pitches.
When should the founder send a personal email?
When a strong signal fires on a good-fit account, a short note from you often beats any banner. Keep it plain text, from your own address, and make it easy to say no.
A template you can adapt:
"Hi Sam, I noticed you passed your booking limit for the second month in a row, so the studio must be busy. Nice. Two options if it helps: the Studio plan removes the limit for $49 a month, or the annual version costs less over the year if you're sure you'll stay. If last month was just a one-off rush, stay where you are; the grace period will cover you. Either way, reply if anything about the limits is getting in your way. (Your name)"
That last option matters. Sometimes the honest answer is "stay on your plan", and a customer with a seasonal spike will trust you more for saying so. Mention annual billing only if you already offer it and it genuinely saves them money. Never invent discounts or deadlines to create urgency.
What happens to billing when someone upgrades mid-month?
Keep the rule simple and say it before they click: upgrades take effect immediately, downgrades at the end of the current billing period.
If you bill with Stripe, its documentation on prorations for subscription changes shows how an upgrade halfway through a period works: the customer gets a credit for unused time on the old price and a charge for the remaining time on the new one. By default those items wait for the next invoice; you can invoice them immediately instead, and preview the amount first to show the customer. In the Customer Portal settings you can let customers switch plans themselves and schedule downgrades for the end of the billing period.
The edge cases (switching from monthly to annual, unpaid invoices, discounts) are covered step by step in this walkthrough of what happens when a customer switches plans mid-month, so this guide won't repeat them.
How do you know if upgrades are working without being pushy?
Track five numbers in one sheet and review them monthly in twenty minutes.
Expansion MRR: the extra monthly recurring revenue from upgrades this month.
Upgrade rate per signal: of the accounts where a signal fired, how many upgraded within 30 days. This tells you which signals are real.
Downgrades within 60 days of an upgrade: the clearest sign that a prompt pushed someone into something they did not need.
Complaints about prompts or limits: tag support messages that mention them, and read every one.
NRR, quarterly: using the calculation above.
If you don't yet have a simple habit for watching your numbers, start with a small set of product metrics before your first 100 users and add these five once upgrades are on your radar.
At this size the numbers jump around, so watch the direction over three months and read the accounts behind every quick downgrade.
What traps make upgrades feel like nagging?
Bait and switch. Moving a feature people already use to a higher plan. If you must, keep it for existing customers.
Dark-pattern buttons. A huge "Upgrade" button next to a tiny grey "no thanks", or a decline link that says "No, I don't want to grow my business".
Upgrading people automatically. Charging someone more because they crossed a limit, without them choosing it, is a fast route to chargebacks and angry emails.
Too many tiers. Five plans that barely differ make people freeze or pick the cheapest.
Pitching free users who will never pay. Hobbyists and curious visitors won't convert because you asked again.
Measuring only upgrades. Ignore downgrades and complaints and you will reward pushy prompts by accident.
A made-up example: how Kettlebook fixed its upgrades
Kettlebook is invented, and so are all the numbers in this section. It is a booking app for independent pottery studios, run by a solo founder called Beatrix. Example data: 140 paying studios, 118 on Starter ($19 a month, up to 150 bookings a month) and 22 on Studio ($49 a month, unlimited bookings plus waitlists and class packs).
For a year, the only upgrade path was a "Go Studio!" modal on every login. In its last three months, two studios upgraded and three complained about the popup.
Beatrix pulled the 22 upgraded studios and the 14 days before each upgrade: 15 had hit or nearly hit the 150-booking cap, 4 had clicked on waitlists and 3 had asked support about class packs. A random 22 Starter studios showed almost none of those behaviours.
She made five changes:
Removed the login modal.
Added the 80% bookings banner and a grace overage until the end of the month, with existing bookings always safe.
Put a locked-feature preview with a 7-day trial on the waitlist and class-pack buttons.
Showed the Studio price and a one-line proration note on the upgrade button; downgrades take effect at the end of the billing period.
Sent a personal email to any studio that went over the cap two months in a row.
Example results after 60 days: 9 studios upgraded, adding $270 in monthly expansion revenue; one moved back to Starter, which she logged for a closer look. She told two studios with a summer rush to stay on Starter, and prompt complaints dropped to zero. None of this is a benchmark.
A 14-day plan to fix your upgrade path
Day | Task | Done when |
|---|---|---|
1 | List every upgrade from the last 6 to 12 months | One sheet, one row per upgrade |
2 to 3 | Pull the 14 days before each upgrade, plus a sample of non-upgraders | Behaviour columns filled in |
4 | Pick your top two or three upgrade signals | Written down in one sentence each |
5 | Check plan boundaries against those signals; ungate anything on the never-gate list | Plan limits match the value that grows |
6 | Remove login modals and timed popups | No prompt without a signal |
7 to 8 | Add the 80% warning, grace overage and "nothing breaks" rule | Tested on a test account |
9 | Add point-of-need upgrade prompts with price and proration line | One click from prompt to new plan |
10 | Add a short feature trial or decide on a reverse trial | Trial ends cleanly without surprise charges |
11 | Write the "on track to exceed" email and the founder email template | Both saved, plain text |
12 | Set upgrades to apply immediately and downgrades at period end | Billing settings checked with a test change |
13 | Build the five-number sheet | Expansion MRR, upgrade rate per signal, quick downgrades, complaints, NRR |
14 | Send founder emails to accounts where a signal has already fired | Every reply answered |
Upgrade FAQ
How many plans should a small SaaS have?
Usually two or three that differ on the thing that grows. If you are still early, one plan done well can be enough; this guide to writing a pricing page when you only have one plan covers that case.
Should I email customers about upgrading?
Yes, when a real signal fires and you can say something specific about their account. No to "upgrade now" blasts to everyone.
Reverse trial or free trial?
A reverse trial gives new users the higher plan for a short time and then moves them to the plan they chose, so they feel what they would lose. A trial of a single feature does the same for existing customers. Pick whichever matches your main upgrade signal, keep it short, and never charge automatically at the end without clear consent.
What is a good upgrade rate?
There is no honest universal number; it depends on your plans, prices and customers. Compare yourself with last quarter: more upgrades per signal, with quick downgrades and complaints flat or falling.
If you are building a SaaS that customers grow into, you can also launch it on IndieHunt, where indie founders share what they build.
