The new default for devs: How PostHog beats billion-dollar incumbents

“I’m writing about how PostHog does the opposite of all the startup advice out there”, I told my software engineer friend, “Really? I love PostHog!”, he replied “With other companies you never know what they do with the data and you’re on some super limited free plan. With PostHog you can just use it.”

If you’re not familiar, PostHog is a “product operating system”. They offer typical tooling used by product teams: Feature flags, A/B testing, analytics (web & product) and a few other things. But instead of selling to product managers, they target engineers.

Before chatting with my friend, I regretted committing to an article about PostHog. When I broke down spreadsheet startups, there were neat frameworks as guardrails. PostHog seemingly ignores most startup advice: The product is open-source, pricing is usage-based and they’re competing in giant categories.

An early-stage startup selling NINE products? Competing against Mixpanel, Amplitude, and Hotjar? Hearing this, my inner VC (my therapist told me to pay more attention to this part of me) isn’t writing a check. He’s sending them off with trite startup advice to hyperfocus on a tiny use case, conquer the niche and then expand. Writing about this company must’ve halved the lifespan of my keyboard’s backspace button.

But when I take off my Patagonia vest, I can tell PostHog is working. According to their website. PostHog eyes a 2026 IPO with $100 million in ARR, and private market research firm Sacra currently estimates PostHog’s revenue at $9.5 million. Others estimate revenue at closer to $5 million. PostHog itself only states “Revenue is growing very quickly, and we're on the way to being profitable.”

That’s why from a happy user boosted my understanding more than dozens of hours of research.

I’ll spare you the vanity metrics, but be assured: PostHog is a fast-growing company  with a popular product. In this article, we’ll explore one core question: How does PostHog get away with ignoring most startup advice?

I interviewed PostHog’s head of marketing Andy Vandervell about exactly this. Here’s how he views it:

PostHog is no contrarian—but it’s deliberately different

"We're definitely a little contrarian, but in the most intentional way possible. It's not about being different just for the sake of it, it's about making choices that make sense for our audience. It's necessary to stand out in a crowded market." 

That’s how Andy explained PostHog’s apparent contrarianism. PostHog might seem to break a lot of rules, but it doesn’t break them just to break them: “A lot of conventions of SaaS companies are kind of silly. There’s no reason your website has to be white and blue. People think if you want to sell to an enterprise company, you need to have a serious website, but we’ve proven that’s not the case.”

This is true. PostHog’s client roster includes giants like Airbus and DHL. It’s not that PostHog is different to be different—they break the rules they don’t see as worthwhile rules.

But PostHog is different in various ways besides having a cute mascot and irreverent marketing copy. Being intentionally different usually rests on unique insights. I asked Andy what those were at PostHog:

“The thing that glues it all together is transparency. We are way more transparent than any normal company.”

This rings true—PostHog publishes most of their internal company handbook and shares their product roadmap publicly. Usage-based pricing is also more transparent. PostHog’s brutal honesty on its website is another expression of that transparency.

How PostHog plays in 9 categories at an early stage

If you can’t be first in a category, set up a new category you can be first in.

-Al Ries & Jack Trout, The 22 Immutable Laws of Marketing

In an interview on Unsupervised Learning, Co-founder and CEO James Hawkins describes PostHog being born out of “a series of bad ideas”: CTO Tim Glaser and him built five fruitless products in five months. Almost as frustrating as repeated failure was setting up product analytics for each.

As he tells it, Hawkins sounds like building product analytics was a last resort: “Maybe we should just do product analytics for developers.”

What might’ve felt like admitting defeat has become resounding victory. James Hawkins describes there were clear pain points. They wanted to self-host (to not lose data to ad blockers) and write SQL to get to the underlying data and have the flexibility to add more features to their analytics. Like many successful startups, PostHog started solving problems so specific no outsider could spot them.

“We knew this would run on HackerNews”, Hawkins recounts. He was right: A viral HackerNews post about open-source product analytics later, the company was up and running.

Today, PostHog’s mission is to “help engineers build better products”. That’s a curious choice: Most product tools—analytics, feature flags, A/B testing, etc.— advertise being no-code or low-code and how you don’t need eng.

This is understandable: In many companies, engineers have a reputation for being overworked curmudgeons who have a 3 week backlog before they can fix a typo in a settings tooltip.

In minimizing engineering involvement, B2B software companies treat engineers as a necessary evil. It’s no surprise that this irks technically-minded folks. James Hawkins doesn’t go on a crusade, but is opinionated about serving technical people: “I have trauma based on my experience with product […] I think a lot of our company is based on chips no shoulders.”

Here’s the opportunity through a Clay Christensen lens: Low-to-no-code made engineers an underserved market segment.

At its current stage, PostHog couldn’t beat Hotjar in session replay. But it can win session replay for engineers. But that’s not the game they’re playing. Product tools for engineers is.

Andy described this strategy as that of a “compound startup”, a term coined by Rippling founder Parker Conrad. The idea: You don’t need to win any individual category if you can offer everything your target customer may need.

According to Andy, the PostHog founders’ lightbulb moment was that self-hosted analytics wasn’t differentiation. But analytics built for engineers was. Most analytics tools are built to for non-technical people, which left engineers underserved.

He described the core insight that: “Engineers should engineer their products, not their data.”

From there, it was easy to discover other tools engineers used (session replay, feature flags etc.), but lacked a solution built for them. This makes it only logical that Andy described PostHog’s goal this way:

“We want to become the default. If you’re a developer building a product or you’re joining a company, we want it to be a no-brainer to use PostHog. You get so much all-in-one that it saves you so much time.”

Why PostHog stopped selling self-hosted licenses

PostHog has shed one of its quirks: Being an opetzn-source product. That doesn’t mean it no longer has an open-source version, but the sales motion has changed: At first, PostHog sold a license to self-host the product. But, as Andy told me, the team has since pivoted away from it:

“We turned it off because it turns out it’s hard to sell a self-hosted service. Plus, it was a bad fit for our product. Anyone who’s running an analytics service knows that ingesting huge volumes of events is very hard to do reliably. So we focused on the cloud-hosted model.”

That’s because open source is a great initial distribution channel, but doesn’t make for great monetization.

How open-source accelerates growth

“Open source is eating SaaS” Hawkins proclaims in on YouTube. This is a strong statement—but does it mean everyone should open-source their work?

Let’s start with the obvious: Give away something useful for free and people will love you. That’s also true with PLG free plans, but open-source goes an extra step—users can self-host, customize and extend your software however they want. This both blessing and curse: You get users without a hosting bill and see what users want based on what they contribute.

Open-source also smoothens your way into companies. Enterprise customers are fun to invoice, but annoying to sell. If you’ve ever been part of a months-long security review, risk audit, or other fun exercise, you’ll know. Open-source code bypasses these because big customers can run it on their own systems. Hawkins mentioned that in week 2 of launching PostHog, one of the world’s biggest banks was using them.

And when it comes to hiring engineers? Pluck them from your GitHub contributors list.

But you can’t pay salaries in GitHub stars. As much as open-sourcing spikes your user charts, it doesn’t do anything for your revenue charts. Until you monetize.

How PostHog monetizes open source software (and makes $10m a year)

If Red Hat’s $34 billion exit to IBM doesn’t convince you that open source can make money, MongoDB’s $26B market cap might. Open source companies typically monetize in one of three ways: Charge for services (support, customization, consulting), offer managed hosting (keeping it easy) or open core.

PostHog uses an open core model: The main part of the product is open-source, while more advanced features are closed-source or source-available, where the customer has the source code but can only use it as long as they pay. By using this model, PostHog has to maintain two versions of the product:

1. The open-source community edition, maintained by PostHog and open-source contributors
2. The source-available paid version, which customers pay for, but get access to the source code so they can self-host it.

That way, they can have their cake and eat it too: Getting the distribution and brand benefits of open-source without losing the ability to get paying customers. The model lets PostHog’s customers (which range from crypto startups like Phantom to giants like Airbus) test the product in their own environment before upgrading—which shields PostHog from the downsides of being open-source.

Wait, downsides?

Why isn’t everyone open-source?

The previous section might’ve read like a case for open-sourcing software products. If you skip past the moral debate and focus on the business effects of open-sourcing your product, you’ll quickly realize that the vast majority of products shouldn’t be open-source (assuming you want to build a business).

PostHog gets away with open-sourcing their product because they target developers. For the purposes of this article, open-sourcing is a distribution strategy. And distribution is only valuable if you reach the right people. Target anyone who doesn’t scour GitHub and open-sourcing becomes a strategic blunder:

First, open-sourcing enables competition: The incumbents you seek to disrupt can use your own code to defeat you. Since PostHog is creating a category, this doesn’t faze them much.

Second, open-sourcing suffers the same weaknesses of free plans: if your free offering is too good, nobody will pay. Which features to open-source and which to reserve for customers is difficult. And unlike with SaaS, you can’t undo open-source like you can move the paywalls in your free plan.

That’s why most software companies shouldn’t be open-source. PostHog makes it work because they target engineers and aren’t trying to win against incumbents.

Another quirk of PostHog’s product/growth strategy is usage-based pricing. As James wrote in our AI SaaS pricing guide, your pricing flows from your cost structure. And when customers largely host your code themselves (because they can run the source code themselves), your costs plummet, meaning you can offer lower costs.

Here’s how Andy described it to me: “If someone looked at our pricing page, they’d tell us ‘you need to simplify this, this is too complicated.’ If our target audience were marketers, PMs or execs, that might be true. There’s a downside to transparency and complexity, but the benefit is that usage-based pricing is tightly connected to the cost to us.”

He also explained the flip side of this: PostHog does no outbound sales, which enables them to offer lower prices than the big competitors that do.

PostHog does offer a cloud-hosted version of their product, showing they’re not zealots in the service of open-source, but pragmatists who discovered a great distribution channel.

In pricing based on usage PostHog sells its product much more like infrastructure. This is a cue to how PostHog views their product strategy: Like infrastructure, PostHog becomes deeply embedded in the product. If engineers customize the product (thanks to the source code being available), it becomes even harder to replace with a closed-source competitor.

But before you’re an integral part of how your customers build product, you need to actually get those users. And if ignoring traditional advice in pricing and product strategy wasn’t enough, PostHog also reverses how product tools are usually bought.

PostHog growth strategy: Enabling a bottom-up motion for high-effort categories.

I can’t find the post right now, but I’ve heard James Hawkins say something like “We don’t really sell to anyone, we basically just wait until 20 engineers on your team demand their manager buys us.”

This is the reverse of how analytics, A/B testing, feature flags etc. are usually bought top-down:

A CPO/PM realizes they need a capabilities to accomplish a goal, so they buy a tool that does it. Engineering gets consulted for feasibility and implementation.

We also have this at CommandBar: Our product does many things, so it’s unlikely a customer would unlock its full power by themselves. That’s why we have sales and customer success functions to aid customers in leveraging our product.

The polar opposite of that is Figma: Individual designers started using Figma and shared the links with their colleagues to show them designs. That way, Figma spread within organizations.

PostHog works more like Figma than CommandBar: An engineer starts building with the code. As PostHog becomes part of the codebase, more engineers work with it. That’s how PostHog spreads within organizations.

Why can PostHog reverse the growth motion from top-down to bottom-up? Usage-based pricing (meaning a cost of $0 until you use it) and open-source code lower the barrier to using PostHog to basically zero. Instead of enduring a procurement process or cajoling a limited free plan into doing the job, engineers can simply build with PostHog: As my friend summarized it: You can just use it.