The Pricing Page: What to Put On It, and What to Leave Off
Picking the number is one problem, presenting it is another. Plan names, the free tier decision, trials and card-up-front, annual billing, and the things founders add that quietly cost them customers.
Posted by
RouzbehRelated reading
Answering Support When You Are the Whole Company
Support is the highest-quality research channel a small product has, and the fastest way to burn out if you treat it as an obligation. How to answer, what to automate, and how to say no.
Why Users Do Not Come Back: Early Retention When You Have Twenty of Them
At twenty users churn is not a metric, it is twenty stories you can read individually. The most common cause is not a missing feature, it is that the problem does not happen often enough to build a habit around.
The First Five Minutes: Onboarding When You Have No Onboarding Team
Most onboarding advice assumes a product team and a tooling budget. At ten users the fix is not a guided tour, it is the empty state, one obvious first action, and doing it by hand while you still can.
Choosing the number is one problem and presenting it is a different one. The pricing page is where your most motivated visitors go, the ones who already believe the product might work for them, and most of the damage done there comes from things founders added rather than things they left out. This is about the page itself. If you have not settled on the number yet, that is how to price your first indie SaaS, and it comes first.
Table of contents
What the page is actually for
Not persuasion. By the time somebody reaches pricing they have already decided the product is plausible, and the job of the page is to let them work out which plan is theirs and whether the number is acceptable. Every element should serve one of those two questions.
The practical test for anything you are considering adding: does this help a specific person recognise themselves, or does it help them decide the price is fair? If neither, it is decoration, and decoration on a pricing page reads as evasion.
The second thing the page does, increasingly, is answer the question when somebody asks an assistant what your product costs. That is a reason to state prices as plain numbers in text rather than burying them in an image or behind a toggle, which I went into in generative engine optimization for indie founders.
How many plans, and what to call them
Two or three. One plan makes the decision binary and removes your ability to serve a second kind of customer. Four or more turns a thirty second decision into a comparison exercise, and people who cannot decide do not buy.
The naming rule that helps most: name plans after who they are for, not how big they are. "Starter" and "Pro" are conventional and almost meaningless, and I use them on Lighthouse because the convention is doing useful work: people already know what they mean. Where you can do better is the line underneath, which should say plainly which person this is. "For your first launch" and "for people running this as a business" do more than any adjective.
What separates the tiers matters more than the names. The gate should be something the customer can predict about themselves, like whether they need an API or a custom domain, rather than a usage limit they cannot estimate in advance. A limit nobody can forecast produces the worst possible experience: they choose, then get stopped mid-work.
The free tier decision
I ran a free tier on Lighthouse and removed it. That is a real decision with real tradeoffs rather than an obvious call, so here is the honest version of both sides.
A free tier earns you volume, word of mouth, and a population to learn from. It costs you support load from people who will never pay, infrastructure spend that scales with non-customers, and, most expensively for a solo founder, roadmap pressure from users whose requests carry no revenue signal. It also makes your numbers harder to read, because a free signup and a paying customer are different events wearing the same clothes.
A rough rule: free tiers make sense when the product has a network effect or a viral surface, where free users generate value for paid ones. If free users are simply cheaper versions of paid users, the tier is a cost centre with a marketing story attached.
One thing worth knowing if you do remove one: existing free accounts are a promise you already made. Keep them working. The cost of honouring a small number of grandfathered accounts is far lower than the cost of being the founder who switched off something people were relying on.
Trials, and asking for a card
With no free tier, the trial is doing the job the free tier used to do, and the main decision is whether to ask for a card up front.
Lighthouse asks for one: you start a seven day trial through checkout, and the card is charged at the end unless you cancel. It is the less friendly option and it is a deliberate trade. Card up front means far fewer trials and a much higher share of them converting, because everybody in the trial has already decided the price is acceptable. No card means more people in the funnel and a large number of them are tourists.
Which is right depends on what you are short of. If you need information and traffic, no card gets you more of both. If you are one person and your scarce resource is attention, card up front filters for people worth spending it on. What is not defensible is asking for a card and hiding it. Say on the page that a card is required, when the charge happens, and how to cancel, because the visitor is going to find out anyway and the only variable is whether they find out from you.
Seven days is a reasonable default. Long trials mostly extend the period before someone decides, and thirty days means they have forgotten why they signed up by the time you charge them.
Annual billing
Worth adding, and not on day one. Annual plans bring cash up front and reduce the number of monthly decisions a customer makes about whether to keep paying you, which is the real benefit. The usual shape is twelve months for the price of ten, which is what Lighthouse does, and it is legible without arithmetic.
Two presentation rules. Show the monthly equivalent alongside the annual total, because people compare in monthly terms and then pay annually. And do not default the toggle to annual to make the headline number look smaller. It is a small deception that gets noticed at checkout, which is the worst possible moment.
Wait until you have a few months of paying customers before adding it. Selling a year of something you have not run for a year is a commitment in both directions.
What to leave off
| Common addition | Why it costs you |
|---|---|
| A countdown or "price rising soon" | If it is untrue it is a lie, and if it is true you have told people to wait and see. Both outcomes are bad. |
| "Contact us" as a third tier | At indie scale this reads as an empty enterprise plan. Nobody contacts you and it makes the real plans look small. |
| Thirty feature rows per plan | Nobody reads past six. The rows that matter are the ones that differ between plans; the rest belong on a features page. |
| A competitor comparison table | On your own pricing page it reads as insecurity. Put it on a dedicated comparison page where the reader arrived looking for exactly that. |
| Testimonials you cannot attribute | An unattributed quote is worth less than no quote, because it invites the reader to wonder whether it is invented. |
The most valuable block on the page
A short FAQ underneath the plans, answering the specific objections that stop somebody buying. Not "what is your product", but the awkward ones:
- What happens to my data if I cancel?
- Can I export everything?
- Do you charge per user?
- What happens when I go over the limit?
- Who is behind this, and will it exist next year?
That last one is not paranoia, it is the honest concern about buying software from one person, and it deserves a real answer rather than silence. Saying plainly that you are a solo developer, that people can export their data at any time, and that cancellation is one click, defuses more hesitation than any feature bullet.
The way to find these questions is to stop guessing them. They are in your support inbox, in the replies to your launch email, and in the conversations from talking to users. Write down every pricing question anyone asks you and put the recurring ones on the page.
Frequently asked questions
Should I show prices at all, or ask people to book a call?
Show them. Hidden pricing is a strategy for sales teams with negotiating room, and you have neither. It also removes you from every comparison a potential customer makes, including the ones an assistant makes on their behalf.
Which plan should I highlight?
The one that suits most people, which is usually the middle or the more expensive of two. Highlighting is legitimate guidance when it reflects a genuine recommendation and manipulative when it points at whichever plan you would prefer to sell.
Do I need a money-back guarantee?
At small scale a stated refund policy does the same work with less drama: refund on request, no questions, within some window. Very few people take it and its presence removes the risk from the decision.
How often should I change the page?
The prices, rarely. The wording, whenever you learn a new objection. Nobody notices copy edits, and every objection you answer is a person who would otherwise have closed the tab.
Should the pricing page be its own URL or part of the homepage?
Both works. A dedicated page is easier to link to and easier for a crawler or an assistant to cite. Repeating the plans on the homepage costs nothing and catches people who never navigate.
Almost everything that goes wrong on a pricing page is a failure of nerve: hiding the number, padding the feature list, adding urgency that is not real, or refusing to say what happens when someone cancels. State the price, say who each plan is for, answer the uncomfortable questions in plain words, and remove the rest. The people reading it are the ones closest to paying you, which makes it the worst page on your site to be vague on.
Lighthouse is a waitlist, survey, newsletter, and feedback toolkit for indie founders, at $19 or $29 per month with a seven day trial. From an indie dev, for indie devs and makers.