Your first SaaS price change: raise it, grandfather your founders (UK, Claude Code 2026)

You launched. You fixed the activation leak, kept a handful of your first cohort, and now you have something you did not have a month ago: a small group of people who pay you real money and keep using the thing. That changes one number you have been avoiding.

Your price.

Almost every solo founder sets their launch price the same way: a guess, anchored to nerves rather than value. You picked a figure low enough that nobody could call it cheeky, because back then you had no proof anyone would pay at all. That was the right call at launch. It is the wrong call now. The placeholder has done its job. This is the runbook for your first real pricing change as a UK founder building with Claude Code, and the headline is simpler than the fear around it: raise the price for new people, protect the ones who backed you early.

Why your launch price was always temporary

When you set your launch price you had zero data. No churn numbers, no usage, no idea which feature people would actually rely on. So you priced defensively. Most founders land somewhere around five to fifteen pounds a month for a first SaaS, picked because it sounds reasonable, not because it reflects what the product is worth.

Now you have evidence. You know roughly how often people use the product, which moment they describe as the thing they wanted, and whether they stick around after the novelty wears off. That evidence is exactly what a price is supposed to be built on, and you did not have it before. Keeping the launch price now is like leaving the scaffolding up after the building is finished. It served a purpose. The purpose is over.

There is a well-worn pattern across solo SaaS launches: founders who raised their price once in the first year did better than founders who never touched it. Not because higher numbers are magic, but because the launch price is nearly always too low, and staying too cheap quietly caps everything. Every future launch, every bit of acquisition, every retained user is worth less than it should be while the price sits below value.

The one rule that removes the risk

Here is the move that makes a first price change safe rather than scary: you change the price for new signups only, and you grandfather everyone who already pays.

Grandfathering means existing customers keep their current rate when you raise the price for new customers. Someone who signed up at nine pounds a month stays at nine pounds a month even after new customers start paying nineteen. That single rule removes the thing founders are actually afraid of, which is not "is the new price right" but "will my early supporters feel betrayed and leave".

They will not, because nothing changes for them. Your founders took a bet on an unproven product built by one person. Letting them keep their price forever, or at least for a long time, is the cheapest loyalty you will ever buy. It costs you a little theoretical future revenue and earns you goodwill, word of mouth, and a cohort of people who feel like insiders rather than early victims. For a UK indie product where trust is most of the sale, that trade is not close.

So for this first change, you are not migrating anyone. You are not sending a nervous "prices are going up" email to paying customers. You are quietly changing the number that new strangers see, and telling your founders the good news that it does not apply to them.

Can you actually raise yet? Read the signals

Before you touch the price, check that you have earned the right to. A price rise multiplies a working product. It cannot rescue a broken one. Three signals tell you that you are ready.

Low churn. People who sign up mostly stay. At your scale you do not need a dashboard for this, you need to look at your subscriber list and ask how many of the last month's customers are still here. If most are, good. If half vanished, that is a retention problem, and raising prices on a leaky product just means fewer people arrive to leak out.

"It feels cheap" feedback. When you talk to customers, does anyone seem surprised by how little they pay? Do they compare you favourably to something that costs far more? That is the clearest buy-signal there is. People rarely volunteer that you are underpriced unless you genuinely are.

A value moment people rely on. You should know your activation event by now, the one action that makes the product worth it. If customers hit that moment repeatedly and build it into their week, you are delivering real value and can charge for it. If the product is still a curiosity people open occasionally, hold off.

If those three are present, you are clear. If churn is high or usage is thin, the price is not your problem this week. Go fix the product and come back.

Pick the number, then stop agonising

Founders lose days here. Do not. Two anchors get you to a sensible figure fast.

Anchor to value. What does the product save or make for the person using it? If your tool saves a freelancer two hours a month, and their time is worth thirty pounds an hour, you are saving them sixty pounds of value. Charging nine for that is absurd. You do not have to capture all the value, but you should not be rounding-error cheap relative to it.

Anchor to UK competitors in pounds. Look at what comparable tools charge British customers. Name the real numbers. If the nearest alternatives sit at fifteen to twenty-five pounds a month and you are at nine, the market has already told you the ceiling is higher than where you are standing.

Then round to a clean figure and commit. For a first change, going from a launch price to something thirty to a hundred percent higher is completely normal, because launch prices start so low. Nineteen instead of nine. Twenty-nine instead of fifteen. Do not split the difference to the pound and do not run a spreadsheet for a week. The exact figure matters far less than the direction, and you can change it again. The real, expensive mistake is staying too cheap for another year.

Implement it safely in Stripe with Claude Code

This is where the build-it-yourself part matters, because doing it wrong is how you accidentally rebill all your founders at the new price and spend a weekend apologising. Done right it is a fifteen-minute change.

The mental model: in Stripe, a Product can have many Prices. A subscription is bound to the specific Price it was created with, and it keeps billing against that Price until you explicitly change it. So the safe pattern is purely additive.

1. Create a new Price object on the same existing Product in Stripe, with your new amount in GBP. Do not edit the old Price. Do not delete it. It stays live so existing subscriptions keep billing against it.
2. Point your checkout flow at the new Price ID. Wherever your code creates a Checkout Session or subscription for a new customer, swap the old Price ID for the new one. This is usually a single constant or environment variable in your Next.js app.
3. Leave every existing subscription alone. You are not iterating over customers, you are not calling the subscription update endpoint, you are not touching anyone who already pays. Untouched means grandfathered, automatically.

Hand Claude Code the specifics and let it make the edit precisely. A prompt like: "In our Stripe integration, we have a new GBP Price ID price_xxx for the existing Product. Update only the checkout-session creation path to use the new Price ID for new subscriptions. Do not modify any code that updates or migrates existing subscriptions. Show me the diff and flag anything that touches existing customers." Keep the diff narrow and read it. A pricing change is on the money path, so it earns a regression check before it ships.

The money-path regression check. Before you push, run the full flow against Stripe test mode: a new customer reaches checkout and sees the new price, a test card completes, the subscription is created against the new Price ID, and webhooks fire as expected. Separately confirm that an existing test subscription on the old Price is completely unchanged. Two paths, both green, then ship. This is exactly the kind of narrow, high-stakes change where ten minutes of verification saves you a customer-trust fire.

Tell your founders the good news

You changed the price for new people. Now turn the change into goodwill by telling the founders it does not apply to them.

A short, plain email does the job. No corporate hedging, no "we value your business". Something like: the price for new customers is going up to nineteen pounds, because the product has grown and that is what it is now worth. You signed up early, when none of this was proven, so you keep your original price for as long as you are a customer. Thank you for backing it.

That email costs nothing and does three things. It reframes a price rise, which customers normally dread, as a perk they personally received. It signals confidence in the product, which makes their own decision to subscribe feel smart. And it is the kind of thing people screenshot and share, which is free, credible marketing from exactly the people whose opinion other UK builders trust.

If you ever do decide to migrate grandfathered customers to current pricing, much later and only once the new price is well proven, the rule there is 30 days notice and a clear reason. But that is a future problem. For your first change, you are not migrating anyone. You are giving a gift.

Measure the right number for four weeks

After the change, watch one metric: new-signup conversion at the new price. Do people still sign up at nineteen the way they did at nine? Over about four weeks you will have a clear enough read.

Deliberately do not stare at total MRR. It is distorted right now, because most of your revenue still comes from grandfathered founders on the old price, so it will barely move and tell you nothing about whether the new price works. The clean signal is only in new customers, because they are the only ones affected. That is what makes a first price change such a good experiment: it is genuinely controlled. One variable changed, one group affected.

If new signups keep coming at the higher number, the price is right and you were leaving money on the table. If conversion falls off a cliff, you have learned that cheaply, on new traffic only, with zero damage to existing relationships, and you can adjust the Price object in minutes. There is almost no downside scenario here, which is precisely why first-time founders should stop fearing it.

When not to raise, and when to stop

A few honest cautions, because credibility comes from nuance.

Do not raise if churn is high. Do not raise if customers barely use the product. Do not raise to fix a revenue problem that is really an acquisition or retention problem in disguise. The price change assumes a small but real base of happy, sticky customers. Without that, you are decorating a leak.

And once you have made the change, stop fiddling. You do not need a pricing dashboard, a willingness-to-pay survey tool, or a tiered enterprise table at thirty customers. You need one new Price object, one happy grandfathered cohort, and four weeks of patience. Pricing is a thing you will revisit many times as you grow. Your job today is just to take the first step away from the nervous placeholder you set at launch, and to do it in a way that keeps the people who believed in you first firmly on your side.

You shipped, you launched, you kept a cohort. You have earned the right to charge what it is worth. Go and change the number.

---

Want a validated idea to build next? Every week IdeaStack publishes one deeply researched UK business opportunity, with real keyword volumes, competitor pricing, SERP analysis, and copy-paste Claude Code builder prompts. Read this week's free report and start building.