I've priced every product I have built, and I have got it wrong more often than I have got it right.
Lucuma. PostLift. SEN Letters UK. Graft'd. dunlin Scout. dunlin Radar.
Each one taught me something different about pricing. Most of those lessons came from getting it wrong first.
Here's how I think about pricing SaaS products and AI tools now. These are principles and the reasoning behind them. I'm not going to quote you results I can't show you.
Price Higher Than You Think You Should
My first mistake was underpricing everything.
On my first product I picked a low number. It felt safe. Not high enough to scare anyone off. Not so low it looked broken.
It was wrong.
The error is pricing the mechanics instead of the problem. Nobody buys a document, or a score, or a generated draft. They buy not having to deal with what happens without it.
So the principle: set the price against the size of the problem, not against how long the build took you. A price that looks steep next to your effort can look cheap next to what the buyer avoids.
The SaaS pricing lesson here: people don't buy your tool because it's cheap. They buy it because it solves an expensive problem.
If your product saves someone £500, charging £50 feels like a bargain. Charging £5 makes them wonder what's wrong with it.
Start higher. You can always drop the price. Raising it later feels like betrayal.
Match the Billing Model to How Often the Thing Gets Used
Before picking a model, ask one question: how often will one person actually need this?
Take SEN Letters UK. It helps parents write letters to their child's school about special educational needs. A subscription looks logical on paper, because a parent deals with that school for years.
But the need isn't continuous. It spikes around a meeting, a refusal or a review, then goes quiet for months.
Charging monthly for a tool someone opens three times a year is charging them for the waiting.
Most people won't agree to that, and the ones who do will cancel the moment they notice.
A one time price fits that shape better. You pay when you need it, and it's there when the next letter is due.
The billing model isn't a money decision first. It's a description of how the product gets used.
Flip it round for something like PostLift, which generates LinkedIn posts. If the job comes round every week, a subscription matches the habit and a one off price doesn't.
The rule: if your product gets used sporadically, go one time. If it's daily, subscription makes sense.
Free Tiers Kill Momentum for Solo Founders
Freemium is the default advice, and it's the advice I trust least as a solo founder.
The playbook is familiar. Give a slice away, charge when someone wants more than the slice.
The part the playbook skips is who answers the questions.
A free user has the same questions as a paying one. Same bug reports. Same feature requests. Same reasonable expectation of a reply.
With a support team, that's a cost you plan for. On your own it comes straight out of build time, which is the one thing you can't buy more of.
So my default now is paid from the start, with a clear refund if it doesn't do what I said it does. The refund carries the risk instead of the free tier.
Here's the SaaS pricing lesson: free tiers work if you have a team to handle support and a budget to burn on acquisition.
If you're solo, free users are expensive. Charge from the start. Let price filter out tyre kickers.
Anchoring Works, But Only If It's Honest
Tiers are where it's easiest to be dishonest without noticing.
The usual shape is three of them. A cheap one, a middle one you actually want people on, and a bigger one for larger teams.
The temptation is to make the cheap tier deliberately annoying so people climb out of it.
It's a bad trade.
People can tell the difference between a limit that exists for a reason and a limit that exists to push them. The second one reads as a trick, and you're asking that same person to trust you with their work.
The honest version is harder to design. Each tier has to be genuinely useful to the person it's aimed at, and each step up has to buy something real: more volume, more seats, a feature a bigger team actually needs.
It's also the only version you can defend in an email.
Anchoring works when your tiers reflect real user needs. It fails when you artificially cripple the cheap option to push people up.
Annual Discounts Are Overrated for New Products
Annual plans get pitched as free cash flow. For a product nobody has heard of, they're a big ask.
Think about what you're actually asking for.
Twelve months of money, upfront, for software they have used for ten minutes, from a company they had never heard of last week, run by one person.
A monthly price is a smaller decision. Early on, the size of the decision matters more than the size of the discount.
An annual option makes more sense once a product has a track record someone can go and check. Before that, the discount solves a problem the buyer doesn't have yet.
The lesson: annual discounts suit established products. At launch, monthly is the easier yes.
Test Pricing by Changing It, Not by Asking
I used to ask people in beta groups what they'd pay.
Waste of time.
What someone says they'd pay and what they actually hand over are two different numbers.
Asking people what they'd pay gives you aspirational answers. Charging them money gives you truth.
Now I test pricing by launching at different price points across channels.
LinkedIn gets one price. Product Hunt gets another. A week later, I compare conversion rates and pick the winner.
Real behaviour beats hypothetical opinions every time.
Round Numbers Feel Lazy, Odd Numbers Feel Thought Through
This one is small, and I hold it loosely.
£10 per month feels like I made it up on the spot.
£11 per month feels like I calculated something.
I have no evidence for that beyond how the two numbers read to me. It's a tie breaker when I'm choosing between two prices I'd be equally happy with, not a reason to pick one.
Treat it as taste, not as a tactic.
Know When to Give Up on a Price
A price is a hypothesis. If it's wrong, the useful thing is to find out quickly.
The failure mode isn't picking the wrong number. It's defending the wrong number for three months because changing it feels like admitting something.
Decide in advance what would tell you the price is wrong, and how long you'll give it. Write it down before you launch, while you're still capable of being objective about it.
Otherwise you'll always find a reason to wait another week.
Change it, watch, change it again. That's the whole job.
What I Do Now
Here's my current process for pricing any new product:
I estimate the value it creates for the user. If it saves them £1,000, I charge £100 to £200.
I check what competitors charge. Not to copy them, but to understand the market anchor.
I pick an odd number slightly higher than feels comfortable.
I launch with monthly pricing if it's SaaS, one time if it's a tool.
I decide up front how long I'll leave it alone and what would make me change it, then I hold myself to that.
Once something sticks, I leave it alone for at least three months.
No freemium. No discounts for the first 90 days. No asking people what they'd pay.
Just launch, measure, adjust.
Final Thought
Pricing isn't a science. It's not even an art.
It's a guess that you refine with data.
Every product is different. Every audience has a different tolerance. You won't know what works until you charge someone money and see if they flinch.
Start higher than feels safe. Adjust faster than feels smart. Trust behaviour over opinions.
That's the only SaaS pricing lesson that matters.
Got a product you're struggling to price? Email me at hello@marvanova.com. I'll tell you what I'd charge.