• Product
  • Pricing
  • Docs
  • Using PostHog
  • Community
  • Company
  • Login
  • Table of contents

  • Handbook
    • Start here
    • Meetings
    • Story
    • Team
    • Investors
    • Strategy overview
    • Business model
    • Objectives
    • Roadmap
    • Brand
    • Culture
    • Values
    • Small teams
    • Goal setting
    • Diversity and inclusion
    • Communication
    • Management
    • Offsites
    • Security
    • Brand assets
    • Team structure
    • Customer Success
    • Exec
    • Experimentation
    • Growth
    • Infrastructure
    • Marketing
    • People & Ops
    • Pipeline
    • Product Analytics
    • Session Recording
    • Website & Docs
    • Compensation
    • Share options
    • Benefits
    • Time off
    • Spending money
    • Progression
    • Training
    • Side gigs
    • Feedback
    • Onboarding
    • Offboarding
      • Product Manager ramp up
    • Merch store
      • Overview
      • How to interview
      • Engineering hiring
      • Marketing hiring
      • Operations hiring
      • Design hiring
      • Exec hiring
      • Developing locally
      • Tech stack
      • Project structure
      • How we review PRs
      • Frontend coding
      • Backend coding
      • Support hero
      • Feature ownership
      • Working with product design
      • Releasing a new version
      • Handling incidents
      • Bug prioritization
      • Event ingestion explained
      • Making schema changes safely
      • How to optimize queries
      • How to write an async migration
      • How to run migrations on PostHog Cloud
      • Working with ClickHouse materialized columns
      • Deployments support
      • Working with cloud providers
      • How-to access PostHog Cloud infra
      • Developing the website
      • MDX setup
      • Markdown
      • Jobs
      • Overview
      • Data storage or what is a MergeTree
      • Data replication
      • Data ingestion
      • Working with JSON
      • Query performance
      • Operations
        • Overview
        • sharded_events
        • app_metrics
        • person_distinct_id
    • Shipping things, step by step
    • Feature flags specification
    • Setting up SSL locally
    • Tech talks
    • Overview
    • Product metrics
    • User feedback
    • Paid features
    • Releasing as beta
    • Our philosophy
    • Product design process
    • Designing posthog.com
    • Overview
    • Personas
    • Testimonials
    • Value propositions
      • Content & SEO
      • Sponsorship
      • Paid ads
      • Email
      • Press
    • Growth strategy
    • Customer support
    • Inbound sales model
    • Sales operations
      • Managing our CRM
      • YC onboarding
      • Demos
      • Billing
      • Who we do business with
    • Growth reviews
  • Table of contents

  • Handbook
    • Start here
    • Meetings
    • Story
    • Team
    • Investors
    • Strategy overview
    • Business model
    • Objectives
    • Roadmap
    • Brand
    • Culture
    • Values
    • Small teams
    • Goal setting
    • Diversity and inclusion
    • Communication
    • Management
    • Offsites
    • Security
    • Brand assets
    • Team structure
    • Customer Success
    • Exec
    • Experimentation
    • Growth
    • Infrastructure
    • Marketing
    • People & Ops
    • Pipeline
    • Product Analytics
    • Session Recording
    • Website & Docs
    • Compensation
    • Share options
    • Benefits
    • Time off
    • Spending money
    • Progression
    • Training
    • Side gigs
    • Feedback
    • Onboarding
    • Offboarding
      • Product Manager ramp up
    • Merch store
      • Overview
      • How to interview
      • Engineering hiring
      • Marketing hiring
      • Operations hiring
      • Design hiring
      • Exec hiring
      • Developing locally
      • Tech stack
      • Project structure
      • How we review PRs
      • Frontend coding
      • Backend coding
      • Support hero
      • Feature ownership
      • Working with product design
      • Releasing a new version
      • Handling incidents
      • Bug prioritization
      • Event ingestion explained
      • Making schema changes safely
      • How to optimize queries
      • How to write an async migration
      • How to run migrations on PostHog Cloud
      • Working with ClickHouse materialized columns
      • Deployments support
      • Working with cloud providers
      • How-to access PostHog Cloud infra
      • Developing the website
      • MDX setup
      • Markdown
      • Jobs
      • Overview
      • Data storage or what is a MergeTree
      • Data replication
      • Data ingestion
      • Working with JSON
      • Query performance
      • Operations
        • Overview
        • sharded_events
        • app_metrics
        • person_distinct_id
    • Shipping things, step by step
    • Feature flags specification
    • Setting up SSL locally
    • Tech talks
    • Overview
    • Product metrics
    • User feedback
    • Paid features
    • Releasing as beta
    • Our philosophy
    • Product design process
    • Designing posthog.com
    • Overview
    • Personas
    • Testimonials
    • Value propositions
      • Content & SEO
      • Sponsorship
      • Paid ads
      • Email
      • Press
    • Growth strategy
    • Customer support
    • Inbound sales model
    • Sales operations
      • Managing our CRM
      • YC onboarding
      • Demos
      • Billing
      • Who we do business with
    • Growth reviews
  • Handbook
  • Strategy
  • Business model

Business model

Last updated: Oct 04, 2022

On this page

  • Why do we work on the open source product?
  • Promises
  • What features are paid only?
  • Creation, Collaboration or Compliance**
  • How does open source benefit from our paid offerings?

PostHog is a for profit company that balances the need to improve the open source code of PostHog with the need to add paid features, or PostHog Cloud, in order to generate income.

We have an open core and cloud business model.

Why do we work on the open source product?

When we work on the open source product, it increases the community size, which means we end up with more features, and thus a better product. This means we get yet more community growth and it also helps with revenue growth since the paid products will also improve.

Promises

  1. We won't introduce features into the open source codebase with a delay.
  2. We will always release and open source all tests we have for an open source feature.
  3. The open source codebase will never contain arbitrary limits (i.e. event volumes, user numbers).
  4. The majority of features made by PostHog will remain open source.
  5. The product will always be available for download without leaving an email address or logging in.
  6. We will always allow you to benchmark PostHog.

What features are paid only?

When PostHog (or a contributor - feel free to message us in advance) makes a new feature, we ask ourselves two questions:

  1. Is this feature for Creation, Collaboration or Compliance?
  2. Would this feature help more users find and use PostHog?

Creation, Collaboration or Compliance**

By default, we launch new things as paid. Then we quickly figure out if we can open source them. We consider it an irreversible decision to "un-open source" something, hence this way of releasing. We aim to promptly convert new features to open source if they are suitable.

  • Creation: if the feature improves our existing open source products and is focused on helping individual contributors then it will be open source. If it's a major new feature or product line it should default to being a paid feature.
  • Collaboration: if the feature helps teams to collaborate on Posthog it should be a paid feature. The exception to this is if the feature will significantly help the community to increase. For example, initially we planned "multiple users" as a feature for the source-available version. However, we decided that having multiple users would help the community to grow, which benefits everyone disproportionately.
  • Compliance: if the feature is disproportionately used by enterprises for compliance it should be an enterprise feature.

How does open source benefit from our paid offerings?

The paid features can increase our revenue, thus our ability to grow and hire more developers, who we will use on both versions of the product.

  1. PostHog contributes many new features to the open source version. Having a viable business model makes it easier for us to invest more here.
  2. Security fixes.
  3. Support until the community can self sustain itself.
  4. Performance improvements.
  5. Running an upgrade server.

Questions?

Was this page useful?

Next article

Objectives and key results

Our mission is to "Increase the number of successful products in the world." Our vision for 2023 is: “Everyone building a product has a clear path to making it successful without losing control of their data.” Our Q4 2022 company wide objective: Average 11% Month Over Month revenue growth through Q4 2022. For the OKRs of each team please see the team pages e.g. Team Experimentation . We discuss the OKRs in every all hands meeting - the team leads explain progress against each key result. The…

Read next article

Authors

  • James Hawkins
    James Hawkins
  • Yakko Majuri
    Yakko Majuri
  • Charles Cook
    Charles Cook

Share

Jump to:

  • Why do we work on the open source product?
  • Promises
  • What features are paid only?
  • Creation, Collaboration or Compliance**
  • How does open source benefit from our paid offerings?
  • Questions?
  • Edit this page
  • Raise an issue
  • Toggle content width
  • Toggle dark mode
  • Product

  • Overview
  • Pricing
  • Product analytics
  • Session recording
  • A/B testing
  • Feature flags
  • Apps
  • Customer stories
  • PostHog vs...
  • Docs

  • Quickstart guide
  • Self-hosting
  • Installing PostHog
  • Building an app
  • API
  • Webhooks
  • How PostHog works
  • Data privacy
  • Using PostHog

  • Product manual
  • Apps manuals
  • Tutorials
  • Community

  • Questions?
  • Product roadmap
  • Contributors
  • Partners
  • Newsletter
  • Merch
  • PostHog FM
  • PostHog on GitHub
  • Handbook

  • Getting started
  • Company
  • Strategy
  • How we work
  • Small teams
  • People & Ops
  • Engineering
  • Product
  • Design
  • Marketing
  • Customer success
  • Company

  • About
  • Team
  • Investors
  • Press
  • Blog
  • FAQ
  • Support
  • Careers
© 2022 PostHog, Inc.
  • Code of conduct
  • Privacy policy
  • Terms