How to add a paywall to an acquired free SaaS without losing your audience

One of the most common acquisitions on Failedups looks like this. A solo founder built a useful tool, never charged for it, accumulated 200 to 2,000 free users, then ran out of energy. You wire $3k, take the keys, and inherit an audience trained to expect zero invoices forever.

Now you need to put a paywall on it without lighting that audience on fire.

I have watched this play out maybe two dozen times. Buyers who pick one of four clear patterns and over-communicate keep most of their users. The ones who surprise people lose 80 percent of the base in a week.

The four monetization patterns

1. Grandfather everyone, only new signups pay

The gentlest move. Every existing user keeps what they had, free, forever. New pricing applies to any account created after the cutover date.

The trade is zero churn in exchange for revenue that ramps from zero. If your inherited audience is not actively growing, you are starting a paid product from scratch with a free legacy tier hanging off the side. Plan for six months of patience.

Pick this when the audience is small but loud. Indie hacker tools, dev utilities, anything where Reddit and Hacker News do the distribution. Burning that goodwill costs more than the MRR you would have collected.

2. Soft paywall with high free tier limits

Cap the free tier at a usage number that catches the power users. Free up to 100 invoices a month, or 5 projects, or 50 API calls a day. Casual users do not notice. The 5 percent of people doing real work hit the cap, and a meaningful chunk upgrade because the alternative is to find a new tool and migrate.

This is the pattern I recommend most often, because it preserves the “anyone can try it” flywheel that probably built the audience. Set the cap high enough that you do not look stingy, but low enough that any serious user hits it within a week.

3. Free for personal, paid for teams or business

Segment by use case rather than by usage. Solo accounts stay free. The moment someone invites a teammate, adds a custom domain, connects a Slack workspace, or wants the SOC 2 page, they land on a paid plan.

This works beautifully when there is a natural team upgrade path, and terribly when the product is fundamentally personal. A clean tell you are in the right spot: the existing base is full of people using it at work on a personal account because their boss has not approved the corporate version yet. You are formalising what they were already doing.

4. Hard cutover to paid

Everyone pays starting on a chosen date, no exceptions. Riskiest of the four. You will lose 60 to 80 percent of users in the first week, and the 20 to 40 percent who stay will pay you. That clarity is exactly what some buyers want.

Only run this when the previous founder’s free tier was so generous it trained the wrong audience entirely. A controlled demolition. Go in expecting it.

What to actually charge

Most buyers of small free products underprice. The instinct is “they were paying nothing, so $4 a month feels generous.” Wrong on two counts. Small audiences need real revenue per user to make the business work, and anyone willing to pay $4 is usually willing to pay $19. You are leaving the difference on the table.

For an inherited audience under 1,000 users, my default range is $19 to $49 per month. Lower and the math does not survive a single refund. Higher and you should be selling annual plans with onboarding calls.

A worked example. You inherit 1,000 free users and launch at $29 per month. A 5 percent conversion is achievable within 90 days if the product genuinely solves a problem. That is 50 paying users, $1,450 MRR. Not a unicorn, but it pays for the acquisition roughly twice over in year one. If conversion lands at 2 percent, $580 MRR tells you positioning needs work before any price hike. If it lands at 10 percent, raise the price.

The communication mechanics

This is the part that buyers screw up more than the pricing. Give 30 days notice. Email every existing user, by name, with a short, honest message. Something close to:

Hi [name]. I bought this project from [previous founder] last month. The product is going to keep running, but to keep it running I need to start charging for it. Starting [date], the price is [number]. If you sign up in the next 14 days, you lock in a “founding member” rate of [lower number] for as long as you stay subscribed. If this is not for you, no hard feelings, your data export is at [link].

That note does three useful things at once. It tells the truth about the ownership change, which most users will not have noticed and will appreciate. It frames monetization as the thing that keeps the product alive rather than the thing that exploits them. The founding member discount also gives early payers a reason to act now, which front loads your revenue.

The list of things to never do is short but load-bearing. Silent charges to cards on file are the fastest way to turn an inherited audience into a chargeback queue. Burying the change in a blog post nobody reads has the same effect, just slower. Deleting free accounts that do not convert is also a mistake, since your future paid base is full of people who said no the first time.

Tools, fast

You do not need to build billing. Stripe Pricing Tables give you a hosted upgrade page in under an hour. The Stripe Customer Portal handles plan changes, cancellations, invoices, and tax IDs with zero UI code. If you find yourself wireframing a billing settings page in week one, stop. Wire those two together, send the 30 day email, and the technical migration is done.

When you have done it right

You will know the paywall worked when the people paying you in month three feel like fans, not hostages. Their replies to your changelog emails get warmer, bug reports come in without sarcasm, and a few of those paying customers start sending the next ones to you unprompted. That is the audience you wanted to keep, and the price they pay is what lets you keep building for them.

After this, the 30 day playbook covers what comes next.