SaaS Pricing Lessons from a Solo Founder
I've repriced every product I've built. The lessons: charge more than you think, simplify your tiers, and never compete on price in a niche market.

Pricing is the hardest product decision and the one most founders spend the least time on.
I've priced multiple SaaS products across aviation, AI, and content tools. Each pricing decision taught me something. Most of what I learned contradicted my initial instincts.
Lesson 1: You're Charging Too Little
My first instinct with every product was to price low. "If it's cheap, more people will sign up." This reasoning is logical and wrong.
Low prices attract price-sensitive customers. Price-sensitive customers are the hardest to serve: they demand the most support, churn the fastest, and complain the loudest. They're optimizing for cost, not value.
Higher prices attract value-seeking customers. These customers evaluate whether the product is worth the price, decide it is, and use it seriously. They churn less because they've made a deliberate investment. They provide better feedback because they're engaged users.
Aviation Infinity's pricing went through three phases:
- Phase 1: Very low monthly price. High sign-ups. High churn. Users who signed up "to try it" and forgot about it.
- Phase 2: Moderate monthly price. Fewer sign-ups. Lower churn. Users who were actually studying.
- Phase 3: Premium pricing positioned against the value of the exam. Even fewer sign-ups. Much lower churn. Users who were serious about passing.
Revenue increased at each phase, not because of volume, but because retention improved and the customers who stayed were the ones the product was built for.
Lesson 2: Simple Tiers Win
I started with three tiers (Basic, Pro, Enterprise). Then I tried four tiers. Then I tried usage-based pricing. Then I tried per-seat pricing.
Every complexity I added to the pricing confused potential customers. "What's the difference between Pro and Enterprise?" "Do I need the Advanced plan or the Premium plan?" Confused customers don't buy. They leave.
I now use two tiers maximum: Free (limited) and Paid (everything). The free tier gives users enough to evaluate the product. The paid tier gives them everything. No feature gating across multiple paid tiers. No artificial limitations to justify premium pricing.
This simplicity has a secondary benefit: it eliminates internal debate about which features go in which tier. Every feature goes in the paid tier. The only question is whether a feature should also be in the free tier (to drive conversion) or only in paid (to drive upgrades).
Lesson 3: Annual Plans Change Everything
Monthly plans feel low-commitment to users. They also feel low-commitment to the founder, because monthly churn creates constant anxiety about MRR.
Annual plans change the economics dramatically. The upfront payment improves cash flow. The longer commitment period reduces churn (users who've paid for a year are motivated to use the product). The annual discount feels like a deal for the user and locks in revenue for the founder.
I offer both monthly and annual, with a meaningful discount for annual (typically 30-40%). The annual adoption rate is higher than I expected. Serious users prefer the commitment because it signals their own seriousness about the goal (passing the exam, building websites, etc.).
Lesson 4: Free Tiers Need Limits, Not Features
The wrong way to create a free tier: remove features. "Free users can't export" or "Free users don't get analytics." This creates frustration because users see the features they can't use and feel punished.
The right way to create a free tier: limit usage. "Free users get 50 practice questions per month" or "Free users can generate 3 websites." The user gets the full product experience within the limit. When they hit the limit, the upgrade feels natural: "I want more of what I already like."
Usage limits let free users experience the product's full value. Feature limits let free users experience a degraded version. The conversion rate difference is significant.
Lesson 5: Don't Compete on Price in Niche Markets
In a niche market (aviation exam prep, AI website generation), the competition is thin. There might be three or five alternatives, not thirty. In this environment, competing on price is unnecessary and harmful.
Niche users aren't comparison shopping across twenty options. They're evaluating the few options that exist. If your product is genuinely better, they'll pay more for it. If your product isn't genuinely better, being cheaper won't save it.
I price Aviation Infinity as a premium product in its category. Not the cheapest option. The best option at a fair price. This positioning communicates confidence in the product and attracts users who value quality over savings.
The small market means that even a modest price premium, multiplied across thousands of users, creates meaningful revenue. And the premium positioning reduces the pressure to race to the bottom.
The Meta-Lesson
Pricing isn't a math problem. It's a positioning problem. The price you charge tells users what kind of product you are, what kind of customers you serve, and how seriously you take your own work.
Charge what the product is worth. Simplify until the pricing is obvious. And remember that the right customers are the ones who are happy to pay, not the ones you had to discount to acquire.
Enjoyed this article?
I write about building products, AI, aviation, and the journey of entrepreneurship. Follow along for more.
Keep reading

Surfyx: What Building a Surf App Taught Me About Distribution
Surfyx is a surf tracking app and social network. Building it taught me that distribution, not features, determines whether a product succeeds in a niche market.

How I Use AI to Run a One-Person Product Studio
I maintain ~20 products solo. AI is not replacing my work, it is multiplying it. Here is how I use Claude and AI tooling to operate at impossible scale.

Building Software for Lawyers: UX Lessons from a Non-Lawyer
What I learned about designing legal software as someone who has never practiced law, and why outsider perspective might actually be an advantage.