Open-Source Product Analytics · Fully Remote
Product development used to mean manually writing code, running analysis, diagnosing bugs, and rolling out changes using dozens of tools.
PostHog is the only platform that acts like a co-pilot for you (and your AI agents) to do it all – autonomously.
We started with open-source product analytics, launched out of Y Combinator's W20 cohort. We've since shipped more than a dozen products, including:
PostHog Code, the only AI devtool that understands your product, not just your codebase.
A built-in data warehouse, so users can query product and customer data together using custom SQL insights.
PostHog AI, an AI-powered analyst that answers product questions, helps users find useful session recordings, and writes custom SQL queries.
We are:
Product-led. More than 450,000 organizations have installed PostHog, mostly driven by word-of-mouth. We have intensely strong product-market fit.
Default alive. Revenue is growing incredibly quickly, and we're very efficient. We raise money to push ambition and grow faster, not to keep the lights on.
Well-funded. We've raised more than $180m from some of the world's top investors. We're set up for a long, ambitious journey.
We're focused on building an awesome product for end users, hiring exceptional teammates, shipping fast, and being as weird as possible.
Transparency: Everyone can read about our roadmap, how we pay (or even let go of) people, our strategy, and how we work, in our public company handbook. Internally, we share revenue, notes and slides from board meetings, and fundraising plans, so everyone has the context they need to make good decisions.
Autonomy: We don’t tell anyone what to do. Everyone chooses what to work on next based on what's going to have the biggest impact on our customers, and what they find interesting and motivating to work on. Engineers lead product teams and make product decisions. Teams are flexible and easy to change when needed.
Shipping fast: Why not now? We want to build a lot of products; we can't do that shipping at a normal pace. We've built the company around small teams – autonomous, highly-efficient groups of cracked engineers who can outship much larger companies because they own their products end-to-end.
Time for building: Nothing gets shipped in a meeting. We're a natively remote company. We default to async communication – PRs > Issues > Slack. Tuesdays and Thursdays are meeting-free days, and we prioritize heads down building time over perfect coordination. This will be the most productive job you've ever had.
Ambition: We want to solve big problems. We strongly believe that aiming for the best possible upside, and sometimes missing, is better than never trying. We're optimistic about what's possible and our ability to get there.
Being weird: Weird means redesigning an already world-class website for the 5th time. It means shipping literally every product that relates to customer data. It means building an objectively unnecessary developer toy with dubious shareholder value. Doing weird stuff is a competitive advantage. And it's fun.
Someone has to make sure PostHog actually gets paid. That's us.
We have 14+ usage-based products, subscription add-ons, and soon seat-based pricing with credit pools. Every dollar PostHog makes flows through what we build. If we screw up, customers lose trust and churn - doesn't matter how good the product is. Execs, product, and GTM teams can't make good decisions without the data we provide.
We launch new products all the time and we always want to do what makes sense for customers rather than fit things into a rigid existing system. That means we need to build billing infrastructure that's modular enough to support whatever we throw at it next, fast enough to iterate on without breaking things, and reliable enough that the numbers are always right. Getting all three perfect at once is impossible - finding the right balance is the main challenge. Are we there yet? Not even close. But you'll help us get there faster.
Scaling our billing system to $100M+ revenue (the hundy) by the end of 2026, and well beyond (the billy?).
Building billing primitives flexible enough that launching a new pricing model doesn't require rearchitecting everything.
Making our usage reporting and limiting near-realtime.
Turning usage and messy raw invoice data into actionable internal reports, accurate forecasts, and compliant financials.
Making all of the above go brrr.
Example projects:
PostHog is generally very open about what we build, but our billing repo understandably isn't. Here's a taste of what we're working on right now though (see our team page for more):
Implementing a new, ledger-based revenue model and re-building all dashboards and investor reports on top of it.
Making billing the source of truth for pricing, subscriptions and invoicing.
Shipping 5+ pricing launches and changes this quarter, including two new pricing models.
Strong backend engineer. Python, SQL, and complex data modeling should feel like home.
Edge cases make you excited, not anxious.
Experience with data pipelines, task queues, and workflow orchestration - we still have a lot of Celery but are leaning more into Temporal and Dagster.
If you've done something manually twice (or seen someone else do it) - you're already building an automation or an internal tool to make it easier.
Happy paths are maybe 10% of billing. You treat error handling, rollbacks, and retries as the actual work - not TODOs you'll "get to later".
You don't need someone to tell you what to build. You've started a company, led a major project from scratch, or shipped an impressive side project.
Nice to haves:
You've built and scaled usage-based billing systems before (and have the scars to prove it).
You get weirdly excited about revenue modeling, forecasting and accounting ledgers.
You have a decent guess which one of these we made up: Q2C / AR / B2R / GAAP / ASC 606 / NRR.
This role is not for you if:
You only want to work with other engineers - billing touches every team at PostHog, from product to finance to GTM to marketing.
You need clearly defined requirements before you start building.
You think billing is a solved problem - we thought so too, once.
If you have a disability, please let us know if there's any way we can make the interview process better for you - we're happy to accommodate!
#LI-DNI