You built something real. It works. People are using it. And then someone asks "how much does it cost?" and you panic, pick a number that feels "not too greedy," and watch half your potential revenue walk out the door.
I've done this. Most indie devs have. We're wired to undercharge because we're afraid of rejection, and because we conflate what something cost us to build with what it's worth to the buyer. These are completely different numbers.
Here's the framework I use now — no theory, no MBA jargon, just what actually works when you're shipping solo.
Stop Pricing by Cost, Start Pricing by Value Delivered
The biggest mistake: you calculate your hours, multiply by your hourly rate, add a margin, and call it a price. This is backwards.
Nobody buying your SaaS cares that it took you 400 hours. They care about one thing: what problem does it solve, and what's that problem worth to them?
A real example: I once priced a small automation tool at $9/month because it felt "fair for something simple." A user told me it saved their team 3 hours a week. At even $25/hour, that's $300/month of value. I was charging 3% of the value I delivered.
The exercise: write down the single most concrete outcome your tool produces. Convert it to dollars. If you can't do that directly, ask three existing users what would happen if your tool disappeared tomorrow. Their answers will tell you more than any pricing spreadsheet.
Anchor your price to 10-20% of the value delivered. It feels uncomfortable. Do it anyway.
The Three Tiers That Actually Convert
Flat pricing is dead for SaaS. Not because tiers are trendy, but because buyers self-select into the right context when you give them options.
Structure that works:
- Free or trial — enough to prove the core value, not enough to run a real workflow. The goal is a qualified lead, not a charity.
- Solo/Starter — one user, core features, priced for "I'll try this properly." This is your volume tier. Price it so the decision is a no-brainer.
- Pro or Team — full feature set, multiple seats, priority support. This is where your revenue actually lives.
The ratio I aim for: Starter at X, Pro at 3-4X. Not 10X. Users can mentally justify 3-4X for meaningful added value. Ten times the price requires ten times the perceived value, and that's a hard sell.
For one-time digital products (templates, ebooks, toolkits), use the same logic but as price anchoring: offer a base version and a "complete bundle" at 2.5-3X. You'll be surprised how many people upgrade.
Freemium Is a Trap Unless You Design It Right
"Just make it free to get users, then convert them." This advice has killed more indie projects than I can count.
Freemium works when:
- The free tier genuinely demonstrates value (not just a feature-crippled demo)
- The upgrade trigger is obvious and natural — hitting a limit, needing a team feature, wanting integrations
- Your conversion rate is north of 3-5%
Freemium fails when your free tier is too generous (nobody needs to upgrade), too restrictive (nobody trusts the product), or when you don't have volume to make the math work.
For most indie devs shipping solo tools: don't do freemium at launch. Do a 14-day free trial on paid plans instead. You get the same risk-reversal without giving away the product forever. Once you have 500+ active users and real conversion data, revisit it.
Anchoring and Packaging: Make the Right Choice Obvious
Pricing is psychology before it's math. Three things that move the needle without changing your actual price:
Annual billing discount. Offer 20% off for annual upfront. You improve cash flow, reduce churn, and the user gets a win. Everyone in SaaS does this because it works. Add it even if you only have 10 customers.
The decoy tier. If you have three tiers, the middle one should look like an obvious deal compared to the top. Most buyers will land on middle-to-top once they see the comparison. Design your feature list with this in mind.
Outcome-based naming. Don't call tiers "Basic / Pro / Enterprise." Call them what the buyer becomes: "Freelancer / Studio / Agency." Now the buyer is choosing an identity, not a price point. Conversion improves.
One concrete example: I renamed a tier from "Pro Plan — $49/month" to "Agency Plan — For teams handling 10+ clients — $49/month." Same price, same features. Signups from agencies doubled in 30 days.
When to Raise Prices (and How to Do It Without Losing Users)
You'll know it's time when: your trial-to-paid conversion is above 15%, you're getting no pricing objections in sales calls, or new signups are accelerating without you doing anything. These are signals you're underpriced.
How to raise without drama:
- Grandfather existing users for 12 months. Announce it clearly. They'll appreciate it and most won't churn — they'll feel lucky.
- Raise for new signups only. You lose nothing on existing ARR and you immediately learn if the new price is viable.
- Add value before raising price. Ship one meaningful feature, announce the upgrade, then mention the upcoming price change. The narrative is "we're improving, the price reflects that."
A 30% price increase on a $29 tool costs you nothing if your churn stays flat. It adds 30% revenue with zero extra work. You don't need more users — you need better-priced users.
The One Thing That Will Change How You Think About This
Pricing isn't something you set once. It's a hypothesis you test, same as any other product decision. Your first price is wrong. The goal is to be wrong fast, collect data, and adjust.
Ship. Price it. Talk to the people who didn't buy. Ask specifically: "What would this need to cost for you to not think twice about it?" The answer is almost never what you expect.
Most indie devs leave 40-60% of possible revenue on the table not because their product isn't good enough, but because they never updated their pricing after launch.
I compiled everything into a practical guide: Indie Pricing Playbook: Charge What You're Worth
Top comments (0)