We’re constantly thinking, debating, and learning about pricing at PostHog:

• Nearly all of our 14+ apps have separate pricing, so we’re always figuring it out for new products, or adjusting it for existing ones.

• Enduringly low prices is a core value, which our customers love. In the last 12 months, we’ve cut pricing for analytics events, session replay, surveys, and data pipelines.

• There are over 100 requests for comments (108 to be exact) about pricing in our private (sorry) product discussions repo, some with over 100 comments on them.

This is what we’ve learned.

1. How you price is who you are

Pricing isn’t just how you make money, it defines your identity, how you market, and how you sell. It’s just as impactful as your product’s functionality or design.

To illustrate, let’s imagine two feature flag tools.

Feature Flags “R” Us charges by seats and flags created:

• Their customers think about every flag and user they add, so they do less of both.

• The flags they do create are more heavily relied on.

This model appeals to companies that ship slowly and make more requests per flag. This means enterprise features, like auditability and access controls, are a priority.

The Flag Company of New York charges by requests:

• Their customers give access to every developer who create many more flags.

• This lets those developers use them more often (e.g. to test in production)

This model appeals to companies who ship faster and want flexibility. They need to be more thoughtful about where flags go in code so they don’t spend too much, which means cost controls and DevEx features, like local evaluation, matter more.

In short, how much you charge often doesn’t matter as much as how you charge. While they’re superficially similar products, how these two products charge leads to a totally different experience, and different sales motions, too.

Remember this: How you price your product should flow from your ideal customer profile (ICP). Our ICP is high-growth startups that are led by product engineers, which is why we’ve chosen a self-serve model and usage-based pricing. It gives product engineers control and they can use as many flags as they please.

2. Charging anything is better than giving it away

It’s easy to give things away, especially zero marginal cost software, but it’s a trap for early-stage startups. Typically, startups delay figuring out pricing because:

1. They are scared no one will pay them

2. They are afraid of getting pricing wrong and damaging growth

3. They think user growth is more important than revenue

But, unless you’re building Facebook, you’re always better off charging something as soon as possible, even if the unit economics don’t add up yet. Why? Because paying customers give you different, and more valuable, feedback than free users.

They care enough about your solution to give you money, so they’ll care more about it improving. They have skin in the game. This is why acquiring reference customers is a core part of finding product-market fit.

Don’t believe us? Consider the fate of Kite, a failed AI coding startup that had 500k monthly active users when it shut down. As the founder reflected in a blog post:

We failed to build a business because our product did not monetize, and it took too long to figure that out.

We sequenced building our business in the following order: First we built our team, then the product, then distribution, and then monetization.

The first three steps worked. They built a “world-class engineering team” and grew the product to 500k developers with “almost no marketing spend.”

But monetization let them down. Those developers did not pay to use Kite. All the work on previous steps did not pay off and they had to shut down after seven years.

If they had charged earlier, they would have learned faster and possibly avoided the “innumerable sacrifices” they had to make it keep the business going for so long.

Remember this: Pricing is just like product. The sooner you ship something, the sooner you’ll learn what users want. Speaking of which…

3. Frequently changing pricing is totally normal

You’ll almost certainly get your pricing wrong, especially if you are charging early. That’s normal, all companies do it.

PostHog’s early pricing was wildly different from our pricing now. In August 2020, we started as a monthly subscription with a limited free tier.

Later, in March 2021, we added our first iteration of usage-based pricing for a single product and have kept iterating on this model ever since.

Finally, in May 2021, we increased our free tier for events 100x and this combination of usage-based pricing with a generous free tier has been the core of our pricing ever since.

All of your favorite companies who aren’t called PostHog change their pricing regularly, too:

• Notion was paid only until 2020 when it added a free tier for personal use. It has since expanded the free tier to remove any paid personal plans, just focusing on paid teams plans.

• Figma launched an enterprise plan in 2022 with more admin tools, workspaces, and access controls. It also raised prices for Figma Design in 2025.

• Intercom reinvigorated and doubled its growth by launching its AI agent, Fin, with outcome-based pricing.

Ultimately, changing your pricing when needed means you'll better align the value you create with how you charge for it. For example, we recently changed how we charge for data pipelines from events ingested to rows exported and triggered events because it aligns better with that users actually used.

Remember this: Pricing changes require good communication. Give customers:

• Plenty of notice about changes. Figma gave three months.

• A warning, grace period, and discount if you’re raising prices.

• The option to keep old pricing unless it is more expensive or you have a good reason not to.

4. Settle free tier debates before they happen

How much free stuff should we give away? It’s easy to either debate this endlessly, or fall into one of two extremes:

1. Give away as much as possible. Users love free stuff, increasing your free tier is a good way to get more users.

2. Charge for everything. This makes more money and money is good.

Ideally, there should be nuance to this. The best way to create this (and settle debates) is to have clear principles for your free tier. For us, these are:

• Hobbyists or pre-PMF startups should be able to use PostHog for free. This creates ultra-valuable word-of-mouth growth. GitHub famously does the same.

• Be more generous than competitors, making it a no-brainer to choose PostHog. This often means a larger free tier with more features. We’re one of the few session replay tools that offers mobile session replay for free, for example.

• Every product should be priced separately. This means separate free tiers for each product. LLM analytics is separate from product analytics, even though they both use “events.”

• Features that increase stickiness should be free with a reasonable limit. A good question to ask here is: “If I were to switch away to a competitor, what would I feel like I am losing?” It’s tough to leave Figma when all your projects and designs are in one place.

Remember this: Principles prevent every discussion about the free tier from becoming a debate, while avoiding the extremes of giving away too much or charging for too little. Pricing principles should guide all your pricing decisions, too.

5. Billing will become a bottleneck

If you want to go beyond the simple subscription model most billing systems offer, you will need at least one engineer dedicated to it.

This has been the case at PostHog as long as I’ve been here. Three years ago, billing was the growth team’s responsibility, but eventually transitioned to a glue team focused on billing, which now has four people and dedicated support engineer.

Why do we need so many people involved in billing?

• It enables us to charge the way we want. It can be tempting to just accept the simple subscription model most billing systems offer, but this limits your ability to have pricing that aligns with your value creation. Our billing team lets us price products, add-ons, and platform packages how we want.

• The billing system needs the flexibility to handle many situations, such as discounts, contracts, credits, invoicing, and weird payment methods (pay by cheque anyone? Please don’t).

• It needs to be reliable. Charge too much and customers will be super unhappy. Charge too little (or miss failed/late payments) and you are literally leaving money on the table.

• It enables us to make more accurate revenue models and projections, which helps us with everything from hiring to fundraising to product roadmaps.

Remember this: Without someone dedicated to billing, pricing launches are painful, your ability to charge users is limited, more errors and unhappy customers pop up, and any decision involving revenue becomes more difficult.

6. Predictable and transparent pricing > simple pricing

Everyone hates being charged more than they expected. This, of course, hurts the customer, but it also hurts you, as it leads to more churn and a worse reputation.

The solution to this, for many companies, is to make their pricing simpler. Fewer tiers, a unified credit system, a single subscription for everything. For B2B companies, this is a mistake as it limits your ability to charge users for the value they receive.

The alternative we recommend is making your pricing more predictable and transparent. Some ways to do this include:

• Creating a transparent and detailed pricing page. Stripe and Twilio are great examples of this. People want to know roughly how much they’ll pay before they start. We take this a step further and list our sales discounts publicly too.

• Give users a clear view on how much they’ve spent so far and how much they are projected to spend. We do this on our billing page, along with a billable usage dashboard and a docs page on ways to estimate your spend.

• Add spend limits. If customers don’t want to pay over a certain amount, respect that, but make it clear what they’ll lose when they hit the cap.

• Help users tune their spend to what they’re actually using. Our customer success team helps a lot with this and we provide docs pages on cutting costs for most of our products like product analytics, session replay, and feature flags. Data infrastructure companies like Snowflake, Supabase, and PlanetScale all offer ways to identify costly queries and resources to optimize their spend.

• Be generous with refunds. For example, we have side project insurance that protects customers from huge bills if their product goes viral.

Some may call this “leaving money on the table” but we see it as doing the right thing. I’m sure others have had success with the dodgiest pricing tactics possible, but the trust we’ve built with customers is core to what makes PostHog successful, so we won’t be changing these.

Words by Ian Vanagas, free tier enjoyer.

This newsletter? Priceless. Subscribe and share to keep it that way.

Subscribed

🦔🤵 Jobs at PostHog

Interested in seeing all 108 internal pricing RFCs? We’re hiring product engineers and more specialist roles like:

• Backend Engineer – Feature Flags

• Software Engineer – Data Stack

• Product Engineer – Platform Features

• Technical Customer Success Manager

📙 More good reads

• I’ve consistently underestimated how important communication is as a CEO – James Hawkins

• How we made feature flags even faster and more reliable – Dylan Martin

• How to Compete in SaaS – Stay SaaSy

• Your pricing is (probably) broken – Kyle Poyar

• Tailscale Pricing v3, plans, packages, and debugging – Avery Pennarun