Pricing a Micro SaaS Product: What I Learned from Three Real Launches

Pricing is the decision founders spend the least time on and regret the most. Across three separate micro SaaS launches, the pricing mistakes I made weren't creative or unusual — they were the boring, common ones that every pricing article warns about, and I made them anyway because in the moment they felt like the safe choice. Here's what actually went wrong and what fixed it.

Mistake one: underpricing to "be competitive"

On the first launch, I looked at two established competitors charging $49 and $79 a month, and reasoned that as the new, unproven entrant I should come in lower — $19 a month felt like the "reasonable" starting point. It got signups. It also meant that after payment processing fees, hosting, and support time, the margin on each customer was thin enough that growth didn't feel like progress — every new customer added support load roughly proportional to the revenue they brought in.

The logic of "price low to compete" assumes customers are choosing on price. In practice, most micro SaaS buyers are choosing based on whether the tool solves their specific problem well, and a price that's suspiciously lower than established competitors can actually read as a signal of lower quality or higher risk — will this thing still exist in six months? Raising the entry price to $39 on the next batch of signups didn't reduce conversion in any way I could detect; if anything, the support questions got slightly more serious and less "just kicking the tires."

The fix that stuck: price based on the value of the outcome to the customer's business, not in relation to what competitors charge or what feels "fair" for a new entrant. A tool that saves someone three hours a week is worth a real number regardless of how new your company is.

Mistake two: shipping with a single plan

The second launch had exactly one plan: $29 a month, all features included. This felt clean and honest — no confusing tiers, no gating features behind arbitrary walls. What it actually did was leave money on the table at both ends. Power users who would happily have paid $99 for higher usage limits and priority support had no path to pay more. Price-sensitive users who only needed a slice of the functionality had no cheaper entry point, so some of them didn't convert at all.

A single tier assumes every customer gets the same value from the product, which is almost never true once you have real usage data. Some customers use one feature lightly; others build their whole workflow around the tool and would pay a premium to not lose it.

Splitting into three tiers based on actual usage patterns I could see in the data (not guessed-at feature bundles) fixed this. A rough shape that's worked well across later launches:

The middle tier should be the one you design around and steer people toward in your copy — it's usually where the majority of revenue ends up once a pricing page has been live for a while, because it's positioned as the "obviously sensible" choice between a limited option and an expensive one.

How the tier boundaries actually got set

The temptation with three tiers is to guess at feature bundles that sound reasonable — "Starter gets X, Pro gets X and Y" — without any data behind where the line should sit. What worked better was pulling actual usage numbers from the single-tier period before splitting: how many projects, exports, or API calls did the median user generate versus the top 10% of users. The Starter cap was set just above what the median light user actually consumed, and the Pro limit was set high enough that only the heaviest quarter of users would ever bump into it. That meant the caps felt generous to normal users (because they were, by design, sized around real behavior) while still creating a natural upgrade trigger for the users getting the most value.

Guessing at these numbers instead of measuring them is the more common approach, and it usually produces caps that are either so low they annoy everyone or so high they never trigger an upgrade at all.

Mistake three: annual discounts that were too deep

On the second and third launches, I offered "save 20%" annual billing, which sounded standard and safe. Except a 20% discount for paying twelve months upfront means you're effectively giving up 2.4 months of revenue in exchange for cash now — a trade that only makes sense if you have a genuine cash flow need for that lump sum, or if annual customers churn meaningfully less than monthly ones (which is often true, but the discount should reflect the actual reduction in churn cost, not an arbitrary round number).

Worse, a large discount on annual plans quietly signals that monthly pricing is inflated to make the discount look generous — sophisticated buyers notice this. On the third launch, dropping the annual discount to a flatter 10-15% (closer to "we'll give you a small break for reducing our billing overhead and churn risk," which is the honest reason to offer one at all) didn't reduce annual signups in any noticeable way, and the monthly price no longer looked like a decoy.

When to raise prices on existing customers

This is the part almost nobody talks about honestly, because it feels aggressive. But every one of these three products eventually needed a price increase, and the mistake wasn't raising prices — it was waiting too long and then doing it clumsily.

A few things that made price increases go smoothly rather than triggering a wave of cancellations:

• Grandfather existing customers at their current price for a defined window (30-60 days), then move them to the new price with clear advance notice — don't grandfather forever, or you end up running two businesses at two price points indefinitely.
• Announce the change with a specific reason tied to product improvements shipped since they signed up, not just "costs went up."
• Send the notice from a real person, not a no-reply automated system — a short, human email got noticeably fewer angry replies than a templated one on the same rollout.
• Raise prices for new customers first, run it for a month, and only then decide whether and how to move existing customers — this gives you a live read on demand elasticity before touching your existing base.

The customers who cancel over a reasonable price increase (say, 15-25%) are disproportionately the ones who were marginal anyway — low usage, quiet, unlikely to become advocates. Losing a slice of that segment while the remaining base pays more is usually a net improvement to the business, even though it doesn't feel that way while you're watching a handful of cancellation emails come in.

Launch discounts and coupons: use sparingly and with an expiry

A related mistake, close cousin to the annual discount problem, was offering an open-ended "early adopter" discount code with no expiration during the first launch. It felt generous and low-risk at the time. Two years later, a meaningful slice of the customer base was still on that legacy discount, and removing it retroactively for existing customers wasn't a realistic option without damaging trust.

What worked better on later launches was a discount with a hard expiry tied to a specific batch or date — "first 50 customers" or "launch week only" — communicated clearly as temporary from the start. That creates real urgency without creating a permanent pricing liability. If you're going to discount at launch, decide the exit condition before you announce the discount, not after you notice how many people are still on it.

Where billing infrastructure fits into pricing decisions

None of these pricing changes matter much if the billing system underneath makes them painful to execute. Changing tiers, prorating upgrades, and handling failed payments gracefully all depend heavily on which billing provider you picked at the start — some make mid-flight pricing changes trivial, others make them a multi-day migration project. I go through the actual tradeoffs in Stripe vs Paddle vs LemonSqueezy for a solo founder's billing stack, which is worth reading before you lock in a pricing structure, not after.

If part of your product involves sending customers invoices or receipts outside of your billing provider's native flow — for annual contracts, custom deals, or manual upgrades — a lightweight invoice generator is often faster to reach for than building custom invoicing logic into your app for edge cases that come up rarely.

A pricing mistake that almost happened on the third launch

Worth mentioning because it's a trap that looks smart on the surface: usage-based add-ons priced as a flat per-unit fee copied from a competitor's rate card, without checking what that rate actually meant for a heavy user's total bill. Early modeling showed that a customer at the top end of expected usage would end up paying nearly four times the Team tier price in add-on fees alone — a bill nobody would accept without a lot of confusion and a support ticket.

The fix was capping the add-on spend at a percentage of the base plan price (add-ons could add up to roughly 50% more than the base tier, then usage above that pushed the customer to the next tier automatically). This is a small detail, but it's the kind of thing that only shows up if you actually model a heavy-usage customer's bill end to end before shipping the pricing page, rather than assuming a per-unit rate that sounds reasonable in isolation will stay reasonable at scale.

The pattern across all three

Looking back, all three mistakes had the same root cause: pricing decisions made to avoid short-term discomfort (looking expensive, looking complicated, asking for money upfront) rather than decisions made from data about what the product was actually worth to the people using it. The fix in every case was the same too — look at what customers are actually doing with the product, talk to the ones who use it heavily, and price closer to that value rather than to what feels defensible in the moment.