How to price a SaaS product in the early stage

To price a SaaS product in the early stage, pick the model that matches how your product actually delivers value, publish three tiers, and put the number that makes you slightly uncomfortable in the middle one. Then write a review date on it. Your first pricing page is a hypothesis, not a commitment.

Almost every pricing guide you can find is written for a company that already has customers, cohorts, churn data, and someone whose actual job is pricing. That advice is fine, and completely useless to a solo founder with zero paying users, because every method it recommends needs data you do not have yet. What follows is the version for the real situation: three models you can defend on day one, a decision tree that gets you to one of them in an afternoon, a founding-member template you can copy, and the part nobody writes down, which is how to change the number later without losing the people who trusted you first.

Why does early pricing paralysis happen?

Because founders treat pricing as a one-way door when almost nothing about it is permanent. Nobody has bought yet. There is no cohort to upset, no forecast to break, no billing migration to run. The blast radius of getting your first price wrong is roughly the size of one dashboard edit and one email.

The paralysis is real all the same, and it has a shape. Founders postpone the number because the number feels like a public verdict on the work. Charging $9 when you privately hoped for $49 is a painful thing to publish. So the pricing page becomes "coming soon," the launch slips, and three weeks disappear into a spreadsheet comparing you to competitors who have thirty engineers and a sales team.

Sequoia's own guidance on the subject makes the useful distinction: pricing is not a finance exercise, it is a statement about the value you capture relative to the value you create, and it is expected to move as you learn more about both. Their guide to pricing your product treats the first price as an entry point into a conversation with the market rather than a conclusion drawn from one. That reframe is the whole cure. You cannot find out what people will pay until you ask them for money, and you cannot ask them for money until there is a number on the page.

So the first rule of early pricing is unglamorous: ship a number with a date attached to it. The date is what makes the number safe to publish.

Which pricing model should an early-stage SaaS pick?

There are exactly three models a pre-revenue SaaS can defend: a time-boxed free trial, freemium, and a capped founding-member offer. Usage-based pricing and enterprise quotes are real models, but both need operational machinery (metering, invoicing, procurement) that one person does not have on day one. Start with one of these three and graduate later.

One implementation detail worth settling before you build anything: whether the trial asks for a card. Stripe's documentation on subscription trials supports both shapes natively, which makes this a positioning choice rather than an engineering one. Cardless trials produce more signups and more tourists. Card-up-front trials produce fewer signups and a far higher share of people who intended to buy. Early on, when what you need is signal rather than volume, the second is usually the better trade.

How do you decide in a single afternoon?

Three questions, asked in order, and you stop at the first one that answers itself. The order matters, because each question rules out a model for a different reason: the first is about your onboarding, the second about your cost structure, the third about whether scale makes the product better.

Reach the bottom of the tree without stopping and you have a free trial, which is the correct default for most software a solo founder ships. The tree is deliberately blunt. Its job is not to find the optimal model, it is to stop you spending a fortnight on a decision you will revisit anyway the moment ten real people have opened their wallets.

Why does the middle tier decide your price?

Because most buyers do not evaluate a price in the abstract, they compare the options in front of them and pick the safe one in the middle. Publish one tier and the visitor has nothing to judge it against except their own guess. Publish three and you have supplied the frame yourself.

That turns a guessing job into a design job. The middle tier is where you want most customers to land, so it carries the features a serious user actually needs. The bottom tier exists to be too small for that person: real, honest, usable, and visibly missing the thing they came for. The top tier exists mostly to make the middle look sensible, and occasionally to be bought by someone whose budget was never the constraint.

Two practical limits. Three tiers, not five: every extra column adds decision cost and subtracts conversions, and a solo founder cannot meaningfully differentiate five bundles of a product this young. And name the tiers after who they are for, not after metals. "Solo, Team, Agency" tells a visitor which row is theirs in about a second. "Bronze, Silver, Gold" makes them read the whole table to find out.

Is underpricing safer than overpricing?

No, and the asymmetry is the most useful idea in this article. Overpricing produces an objection. Someone tells you the price is too high, and now you have facts: what they compared you to, which budget it would have come from, what feature would have justified it. That is a conversation you can have this week and act on next week.

Underpricing produces silence. Nobody writes in to say your product is suspiciously cheap. They quietly assume it is small, sign up in larger numbers than you can support, generate a support load your revenue cannot fund, and set the market's expectation of what this category costs. Every one of those effects is invisible in your dashboard. What you see is signups going up.

Overpricing gives you an objection. Underpricing gives you silence, and silence is not feedback.

There is a second cost that is harder to reverse. Price is a quality signal in software, particularly for business buyers, where a number that looks too low reads as a hobby project rather than a bargain. A buyer choosing tooling their own work will depend on is not hunting for the cheapest option, they are hunting for the one that will still exist in a year. A price that could not plausibly fund the product answers that question badly.

And underpricing is genuinely hard to undo, because the fix eventually means raising prices on the exact people who believed in you first. That is survivable, as the next section covers, but it is a debt. Discounting your future revenue to buy present-day comfort is the same trade founders make when they sell lifetime deals, and it deserves the same scrutiny.

A workable heuristic while you have no data: name the price you think is right, then say the next number up out loud to a founder who has priced something before. If you cannot defend the higher number for sixty seconds, keep the lower one. If you can, you have been underpricing.

The founding-member offer template

A founding-member offer is a capped, time-boxed launch price that sells your intended list price at a fixed discount, locked for as long as the subscription stays active, in exchange for direct feedback. It is the safest way to charge money before you have proof, because the cap and the end date stop the discount from quietly becoming your permanent public price.

Six parts, all of which belong on the page:

The obligation clause is the part founders leave out, and it is the part that makes the whole thing work. A founding member who knows the discount was bought with candor will actually answer your emails. A founding member who thinks they simply caught a sale will not. Twenty five people who reply is a research budget you could not otherwise afford, and it is how most founders end up closing their first ten paying customers.

How do you raise prices later without a riot?

Grandfather existing customers, give at least thirty days of notice, raise the price for new customers first, and say plainly what the increase pays for. Most of the churn founders blame on a price rise is caused by the surprise, not by the number.

The sequence that works is boring on purpose. Change the public pricing page first, so new signups pay the new rate immediately and you get a clean read on whether it converts. Leave existing customers alone for a full billing cycle while you watch that. Then, if the new price is holding, email existing customers with the date their rate changes, what it changes to, and what shipped in the product to justify it. If a cohort was explicitly promised a locked rate, and your founding members were, honor it permanently. That promise was part of what they bought.

One more thing worth saying to yourself before you send that email. A price rise you can justify is evidence the product got better, and the customers most likely to leave over it are usually the ones generating the most support for the least revenue. Losing a few of them is not the failure case. Losing the trust of the ones who stay is.

How do you test a price with no traffic?

You put the pricing page in front of people who have set a price themselves and ask them a specific question, because you do not have the traffic for a split test and you will not have it for months. An A/B test needs thousands of visitors before it says anything. Twelve founders who have priced a product can tell you in an afternoon that your middle tier is missing the one feature that justifies it.

The trick is in the question. "What do you think of my pricing?" gets you opinions about button colors. These three get you answers:

1. Which tier would you buy, and what nearly stopped you? The hesitation is the finding. The choice is just context.

2. At what price would this be so cheap you would question the quality? Most founders have never heard the bottom of their own range said out loud, and it usually sits above what they were planning to charge.

3. What would have to be true for the top tier to be worth it? That answer is your roadmap, already priced.

Getting those answers is a distribution problem, which is what the structured-feedback action on Favors.dev exists to solve. You do a verified marketing favor for another founder, earn points, and spend them on structured feedback about your own pricing page from founders who have shipped one. Every exchange is verified before any points move, so nobody is trading compliments. It is the same reciprocal loop the rest of a solo founder's GTM strategy runs on, pointed at the one page that decides whether any of the rest of it earns money.

There is a quieter reason to care how your price gets discussed in public. When someone asks an AI assistant whether your product is worth the money, the answer is assembled from whatever the model can find: review sites, community threads, comparison pages. Similarweb's analysis of the domains large language models cite most shows how heavily those answers lean on community and review sources rather than on vendor pages. Your own pricing page does not get the last word on whether your price is fair. The people who have used the product do, which is one more reason to have a directory page collecting honest reviews before you need it.

Frequently asked questions