Three pricing mistakes I made in my first SaaS year

Pricing was the first hard problem in my first SaaS year, and I broke it in three ways that I’d recognise now in any first-time founder’s deck. None of these mistakes felt like mistakes at the time. Two of them felt like the safe move. The third — the free tier — felt like the smart move. Each one cost money I couldn’t easily get back, and one of them nearly cost the willingness of my early customers to stay.

The numbers below are mine. Read them as illustrative rather than prescriptive: the shape of these mistakes generalises across founders, but the specific dollar figures, churn rates, and timing windows in your business will look different in places that matter.

Pricing low so I’d never need to defend it

I launched at $9 per user per month while three competitors were charging between $39 and $79 per seat for products that, on paper, did about the same thing. I told myself I was being clever. The story I sold myself was that I’d own the bottom of the market, scale through volume, and figure out monetisation later. The story was a lie. What I had actually done was build a customer base who paid $9 because that was the deal we struck, not because $9 was the right price for the product.

Ten months in, I tried to move the public price to $19. About a third of my paying users left within six weeks. Maybe 35% if I’m being precise. The ones who stayed were furious in ways that took weeks of one-on-one calls to repair, and a handful wrote public reviews referencing the price hike, which anchored prospects’ expectations downward for months afterward. The compounding effect was worse than the churn itself.

What I should have done is launched at $24 with a 50% lifetime founder discount for the first 30 customers. Same effective revenue from those early cohort buyers. A fundamentally different conversation when I needed to take the price up for the public tier later. Founder discounts feel earned. Price hikes feel like betrayal.

The deeper lesson is that your launch price is your reference price. Customers don’t track your costs or your roadmap. They track what they paid you the first month, and they call any number above that “more than I used to pay”. Watch how your CRM data tells the story when you segment cohorts by entry price. In every business I’ve watched run that experiment, the early-cheap cohort churns faster on every price test, every single time.

That is why I point first-time founders at a CRM like Salescamp early. Not because the CRM does the pricing for you. It doesn’t. Because the cohort data is what makes pricing arguments concrete rather than vibes-based.

Building a pricing page before having a product anyone wanted

The second mistake was structural. I spent three weeks building a four-tier pricing page with a feature-comparison grid, a per-seat slider, an annual toggle, an enterprise “contact us” button, and a tooltip on every feature. I copied the layout from a well-funded competitor whose sales team had clearly informed which features lived at which tier. I had no sales team. I had nine paying users. I had no idea which features mattered enough to pay-gate them.

What that pricing page did was lock me into commitments I hadn’t earned the right to make. I told prospects, in print, that feature X was Pro and feature Y was Enterprise. Then I learned over the next quarter that feature X was the only thing my actual buyers cared about, and feature Y was a feature nobody used. Moving X down to Starter looked like a discount. Moving Y up looked like a bait-and-switch. The page constrained the product instead of the product driving the page.

The version that worked in retrospect was a single price, a single tier, a “what you get” list under it, and a “talk to me about volume” link for the few customers who needed something different. Stripe’s one-click subscription handled the implementation. The full feature-grid pricing page came back nine months later, after I’d watched four cohorts use the product end-to-end and the actual buyer-validated tier structure had emerged.

If you are under 50 paying customers, your pricing page should be approximately 200 words long. Anything more is theatre.

A free tier that ate the paid tier

The free tier was supposed to be the funnel. The free tier became the destination. I gave away three projects, three users, and 1 GB of storage. Generous numbers I picked by looking at the free tiers of competitors who were flush with venture money and could afford to subsidise free users out of their war chest. I had no war chest.

The result was predictable in retrospect. About 96% of signups landed on Free, and roughly 0.6% upgraded to paid. The 96% generated support tickets, used compute, asked for feature improvements that benefited only free users, and posted on Twitter when the product had a wobble. They were not customers in any economic sense. They were a marketing channel that cost more than it returned.

The free tier I would build now is one project, one user, 100 MB, and a 14-day usage cap before a single low-friction paid trigger appears. Or no free tier at all, and a 14-day full-feature trial instead, which is what I eventually moved to. Free tiers work when you have already validated that the upgrade path is a strong default. They do not work as the first thing you ship.

The automation around upgrade nudges matters more than the tier limits themselves. A clean trigger from “user hits the cap” to “in-app prompt plus email plus light follow-up” is the actual product, not the cap. Pabbly Connect is one of the cheaper ways to wire that up if you are not on a sales-led plan; the LTD pricing means the upgrade-funnel infrastructure is a one-time cost rather than a recurring expense that scales with the very free users you are trying to convert. The GrabLTD software directory lists more options by category.

A small ops dashboard, even something like Motherboard for KPI tracking, would have shown me the free-to-paid ratio earlier than my gut did. I did not have one until month nine. I should have had one by month two.

One more thing: annual-only billing in year one

Annual-only billing in year one is a mistake. I know it feels like cash in the bank, and most SaaS playbooks push you toward annual upfront. The trade-off is that annual hides churn. You will not see the customers who would have left at month three until month thirteen, and by then you have made twelve months of decisions on flawed retention data.

In year one, you need monthly cash-flow visibility into who is actually using the product. Annual-only billing buys you cash you cannot optimise against. Offer both, default to monthly, and give a 15-20% discount for annual to pull the customers who genuinely value the product enough to commit upfront.

The three mistakes — the cheap launch price, the over-engineered pricing page, the over-generous free tier — are pattern failures, not one-off blunders. The unifying thread is that I was making promises in public when I should have been having conversations in private. Pricing is a conversation. Treat it as one for as long as you can. If you have a quiet first year, use it: the freedom to move a price without a thousand customers reading the change notes vanishes the moment you start to scale, and almost every founder I’ve watched waste that quiet window has regretted it later.

Share via
Copy link
Powered by Social Snap