Most SaaS founders spend a weekend on the pricing page and get stuck. Not on the code -- on the decisions. How many tiers? Free trial or freemium? Monthly only or annual too? What goes in the "Pro" plan that is not in "Starter"?
The answers are not universal, but there is a framework that works for most early-stage products. And once you decide, wiring it up in a Next.js app with Stripe is faster than you think -- especially if you start from a Next.js SaaS boilerplate that already has subscriptions, plan gating, and trial logic built in.
Start with two. One free or entry-level plan, one paid plan. Adding a third tier before you have customers creates analysis paralysis -- visitors compare tiers instead of committing.
The exception: your customers split cleanly into individuals and teams. Then three tiers make sense from day one.
A structure that works for most micro-SaaS products:
The mistake most founders make is drawing the line in the wrong place. If the difference between Free and Pro is just "more of the same thing", customers will wait. Make Pro unlock a qualitatively different outcome.
Freemium keeps a free user on your product indefinitely. A free trial gives them full access for a fixed window, then asks them to pay or leave.
Free trial wins for most B2B SaaS products. It forces a conversion decision. Freemium wins when you can monetize at volume or when the free tier is a genuine part of your distribution strategy -- your free users recruit paid users.
The Next.js SaaS boilerplate ships with Stripe trial periods already wired in. You set the trial window at checkout, track status in the database, and send a reminder email before expiry. See the Stripe trial periods post for the full implementation pattern.
Offering an annual option at a 20% discount is almost always worth it. You get cash upfront and reduce churn; the customer gets a better price.
The UI pattern that converts: show monthly pricing by default with a toggle above the pricing cards. When the visitor switches to annual, reveal the discounted price and a "you save X%" badge. Do not bury the toggle below the cards.
In Stripe terms, annual billing means two separate Price IDs -- one for monthly, one for annual. Your checkout flow reads the active toggle state and passes the right Price ID to Stripe Checkout. The boilerplate stores Price IDs as env vars and creates the session server-side, so swapping in the annual ID is a one-line change per plan.
Keep it scannable. Each plan card needs:
Below the cards, add a short FAQ that addresses the three objections you actually hear: "Can I cancel?", "Do you offer refunds?", "What happens when my trial ends?"
Avoid a massive comparison table with 40 rows and checkmarks. Nobody reads them. If you have more than 8 features per plan, you have too many features or too many plans.
The pricing page is a promise. The app enforces it.
The boilerplate's usage limits and plan gating pattern stores the Stripe plan on the user record and checks it in the service layer. Routes stay thin -- they call the service, the service throws a 402 if the user is on the wrong plan, and the route returns the error. No business logic bleeds into the route.
This means when you add a new paid feature, you add one check in one service file. The pricing page, the Stripe product, and the feature gate all point to the same source of truth.
Your first pricing page will be wrong. Every founder's is. The goal is to get it live fast enough to collect real data -- who converts, where they drop off, what they ask.
The boilerplate gives you the layout, the Stripe connection, and the plan gating already wired. You decide the tiers, the price points, and where to draw the Free/Pro line. Those are the decisions only you can make -- and you get better answers from a live page than from a spreadsheet.
Get the Next.js SaaS boilerplate and have your pricing page wired to real Stripe plans in an afternoon. Adjust the numbers once you know what the market will pay.