Explain a SaaS Pricing Change While Building in Public

The short answer

State the new price, billing unit, affected customers, and the renewal when each group first pays it. Explain the product decision publicly, provide account-specific details privately, and reconcile earlier pricing promises. A transition cutoff is not necessarily every customer’s first new-price charge.

Explain a SaaS pricing change by stating the new amount, billing unit, affected customers, and the first renewal at which each group pays it. Then explain the product decision behind it. When you build in public, connect that explanation to your earlier pricing posts so readers can follow what changed without guessing about their own bill.

A useful public update lets a prospective customer understand the offer and an existing customer find their specific next step. A thoughtful founder story still leaves work unfinished if an annual subscriber cannot tell whether the new price applies next week or next year.

The method below combines a public decision note with a record of three customer paths. The worked example is fictional. Its prices, dates, product details, and customer situations illustrate the method; they are not Buildside prices or observed customer results.

Separate the price decision from the announcement

Start after you have decided what to charge and whom the change affects. If you are still collecting opinions, say that you are exploring pricing. If you are running an offer test, describe its boundaries. Once you have adopted a price, state the decision directly rather than presenting an open question whose answer can no longer change it.

Our guide to testing SaaS pricing while building in public covers the earlier job: distinguishing audience reactions from evidence of willingness to pay. This article covers the next job, making the adopted offer and transition understandable.

That distinction matters to your public audience. “Would you pay more for this?” invites a product discussion. “The monthly price will rise from US$12 to US$15 per workspace” communicates a decision. You can still invite questions about confusing terms, missing customer situations, or the product direction. Be clear about which parts remain open.

Write the customer paths before the founder story

For each affected group, write down the current charge, future charge, billing period, trigger date, and action available. Add the unit being sold: a workspace, seat, project, channel, or usage allowance. Name the currency. If taxes or usage charges sit outside the figure, say so.

A calendar cutoff and a customer's renewal date are different pieces of information. The cutoff defines which renewals use a new price. Each account's renewal determines when that account actually encounters it. An announcement that gives only the cutoff can leave several customers with different interpretations.

Slack's published explanation of its June 2025 plan changes illustrates this distinction. It specified that website-purchased Business+ plans moved to the new version at the first renewal after August 17, 2025. Customers with account-executive contracts were directed to their account executive, and eligible workspace owners could find renewal dates on the Billing page. This is a historical communication example, not a statement of today's Slack prices.

For a small SaaS, the groups may be simpler. Still check annual subscriptions, discounts, negotiated agreements, and customers who bought through a different channel. A public rule that works for most accounts needs an explicit route for the accounts it does not cover.

A fictional transition with three different first charges

Imagine a small scheduling SaaS called Session Ledger. It charges per workspace, with no seat-based or usage charges in this example. Its founder announces a price increase on November 10, 2026. New signups use the new prices from December 1, 2026. Existing customers move at their first renewal on or after February 1, 2027.

The old prices are US$12 billed monthly or US$120 billed annually. The new prices are US$15 billed monthly or US$150 billed annually. All figures exclude applicable tax. Both billing options increase by 25%; that arithmetic describes the fictional offer, not an industry benchmark.

The founder writes these customer paths before drafting the public post:

The annual customer's January 2027 renewal falls before the cutoff. Under this fictional policy, that customer renews for another year at the old price. “All customers pay the new price in February” would therefore be wrong, even though February is the transition cutoff for existing accounts.

This is the useful test for your own announcement: can you take one real account from each affected group and name its next charge and first new-price charge? Check the billing setup against the written policy. If the two disagree, resolve that before posting a confident public explanation.

The record also exposes decisions you may have overlooked. What happens if the monthly customer switches to annual billing before February? What if a discount expires on the same renewal? Decide and document those paths before offering them publicly. A tidy example does not resolve unexamined exceptions.

Publish a decision note customers can use

Lead the public note with the change. Follow with a short reason grounded in what you can support, then show the transition and the route to account details. Keep a stable explanation available alongside shorter social posts.

Stripe's pricing review framework, updated October 1, 2025, recommends preparing customer-facing teams, explaining what changes and when, giving a reason, and leaving room for questions. Treat that as operational guidance. It does not establish that a particular announcement will prevent cancellations.

For Session Ledger, a fictional public opening could read:

Session Ledger's prices are increasing. New signups from December 1, 2026 will pay US$15 per workspace billed monthly or US$150 per workspace billed annually, excluding applicable tax. Existing customers keep their current price until their first renewal on or after February 1, 2027. Your account notice will show your next charge and the date the new price first applies to you.

A second paragraph could explain the decision in plain language. Suppose the fictional founder has chosen to fund ongoing maintenance of the shared scheduling workflow through a higher subscription price. State that choice. Link to relevant shipped work if it actually supports the explanation. Do not invent an infrastructure-cost increase or claim that every customer receives a financial return.

Building in public gives you room to show the tradeoff: what you considered, what you chose, and what remains uncertain. It does not require publishing private margins, customer invoices, or negotiations. A short honest reason is more useful than a long account of how difficult the decision felt.

Avoid making future features sound available today. If a higher price supports planned work, identify that work as planned. Customers should be able to distinguish the service they are buying now from the founder's intended direction.

Send account details through an account-specific route

Use the public update for the shared explanation and a direct notice for the recipient's actual situation. A customer should not have to comment publicly with an invoice to discover which rule applies.

For the fictional annual customer, the important part of the notice would be:

Your next annual renewal is January 15, 2027, at US$120 per workspace, excluding applicable tax. Under the announced transition, your first renewal at US$150 per workspace will be January 15, 2028, excluding applicable tax. Review your subscription settings for your current plan and available account actions, or contact us privately if these details do not match your agreement.

Only name account actions that actually exist. If cancellation, plan switching, data export, or a lower-cost option is available, explain where to find it and the relevant timing. Do not offer a switch that billing cannot honor or promise a refund policy you have not checked.

Choose notice timing from your actual agreements, sales channels, billing process, and applicable requirements. There is no universal notice period established by this fictional example. A public founder post also does not establish that every affected account received its notice.

For a solo founder, the same person may prepare the policy, answer questions, and check billing. Keep those checks distinct even when one person does all three. Before posting, read the customer notice as if you had never followed the build-in-public story.

Reconcile earlier public pricing promises

Search your public product page, pinned updates, launch posts, and earlier pricing discussions for promises that may now be misleading. Pay particular attention to wording about keeping an early price, lifetime access, included features, or future increases.

Some old posts simply describe the price at the time. Preserve that context and link to the current offer where readers are likely to rely on an outdated figure. Other posts make an ongoing promise. Reconcile that promise with the actual transition before announcing that all existing customers will move.

Use a short review record:

• Earlier statement: what did the public post actually promise, and to whom?

• Present status: is it historical context, a continuing commitment, or a statement that needs correction?

• Current explanation: where can a reader find the applicable price and transition?

• Customer exception: does a particular group need separate handling before publication?

This is where building in public creates a useful discipline. The new decision sits beside a visible history. Explain the change without pretending you always intended it. If the earlier statement was factually wrong, follow the process for correcting a build-in-public update, including enough context for someone who saw the original claim.

Answer objections without turning them into testimonials

Separate a confusing announcement from disagreement with the price. “When does this apply to me?” may reveal missing information. “I understand it, and it no longer fits my budget” describes a different problem. Answering the first does not eliminate the second.

Invite specific questions: which customer path is missing, which billing term is unclear, or which current product limitation matters to the decision? Route account details privately. Publish a clarified shared rule when the answer helps other readers, while keeping individual agreements out of the thread.

Avoid treating supportive founder replies as evidence that customers accept the increase. Those peers may not buy the product. Likewise, a few critical replies do not establish a cancellation rate. Describe what you actually observed, including who was exposed to the change and which renewals have occurred.

For the next public follow-up, choose a date after a meaningful group of affected renewals. Report any results with the relevant customer group, dates, and limits. If only monthly customers have renewed, annual acceptance remains unknown. Communication clarity and commercial success are separate questions worth tracking separately.

Before publishing, ask someone to read the public note and identify the next charge for each of the three fictional customers above. Then repeat the check against your own affected account groups. Every wrong answer points to wording or a policy detail you can fix before customers have to ask.

Questions founders ask next

What if only new customers get the new price?

Say that directly and define who counts as an existing customer. Explain what happens after cancellation, reactivation, a plan switch, or added usage if those events change eligibility. Do not describe an old price as permanent unless that is the commitment you can honor.

Should a founder publish every pricing exception?

Publish the shared rule and identify groups that need a separate account check. Keep individual negotiations, invoices, and customer identities private. A public explanation can acknowledge that agreements differ without exposing their terms.

Sources

• Slack: historical plan-change explanation and renewal paths

• Stripe: pricing review, rollout, and communication guidance

• Buildside: test SaaS pricing while building in public

• Buildside: correct a build-in-public update

Frequently asked questions

A note from Uriel Bitton

I share practical lessons from building Buildside and learning alongside SaaS founders.

Keep building with us

Get practical founder lessons and product updates in your inbox.

Subscribe or Join Buildside.

Keep reading