We're shipping every product that companies need to run their business from their first day, to the day they IPO, and beyond. The operating system for folks who build software.
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:
A built-in data warehouse, so users can query product and customer data together using custom SQL insights.
A customer data platform, so they can send their data wherever they need with ease.
PostHog AI, an AI-powered analyst that answers product questions, helps users find useful session recordings, and writes custom SQL queries.
Next on the roadmap are CRM, Workflow, revenue analytics, and support products. When we say every product that companies need to run their business, we really mean it!
We are:
Product-led. More than 100,000 companies have installed PostHog, mostly driven by word-of-mouth. We have intensely strong product-market fit.
Default alive. Revenue is growing 10% MoM on average, 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 $100m 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.
We spend tens of millions of $ a year on infrastructure.
To be clear: that isn't the problem. We’re growing fast, and building a world-class product costs money. The problem is that right now, cost optimization is a "hot potato." Engineers get pulled into it reactively when a bill spikes, Finance lacks the technical context to know which levers to pull, and nobody is steering the ship.
We are looking for a FinOps engineer that packs the technical chops of an SRE, but brings experience with cloud cost management & capacity planning. Someone technical enough that engineers trust their architectural advice, but commercially minded enough to partner with Finance and explain the why behind our spend.
We’re looking for:
Enthusiastic drivers. We need proactive people that can fully own projects and get them done, and know to get help when needed. "Are we there yet?" is the wrong question.
Optimistic problem solvers. Creating a balance between cost and productivity is not easy. Finance and Engineering teams will have their priorities and you’ll have to solve the puzzle of optimizing for both. This should be a positive challenge for you that gives you energy.
Grown ups. We’re an international bunch of weirdos, but one thing unites us: everyone is kind, considerate, and professional towards each other. This isn't about age or experience, it's about being low-ego, flexible, and respectful.
Genuine builders. PostHog is full of people who just love building stuff, people who would still be building software even if there wasn't a paycheck at the end.
Most companies treat FinOps like a janitorial service: engineers make a mess, and the FinOps person follows them around with a broom and a spreadsheet of "unattached EBS volumes."
That is not this job!
At our scale, we aren't interested in "saving money" in the abstract. We’re interested in efficiency as a product feature. Every dollar we shave off our unit economics is a dollar we can pass directly back to our customers, making our product more competitive and our margins healthier.
We’re shifting FinOps left!
We believe the most expensive line of code is the one written without considering how it scales. We want to move cost conversations from the billing cycle to the design doc. In this role, you aren’t a gatekeeper; you’re an enabler. You’ll be successful when:
cost is a first-class citizen: Engineers treat "cost per query" or "cost per ingest" with the same rigor they treat latency or availability. You’ll be the person engineers go to when asking, "Will this architecture be expensive?" and have the credibility to provide the right answer.
the "hot potato" dies: No more reactive scrambles when the AWS bill hits. You’ll build the systems that give teams the autonomy to own their own margins.
cultural compounding: You shouldn't be a hero who personally finds $2M in a closet. You’ll be the architect who builds a culture where 100 engineers make 1% better decisions every day.
Own the strategy and enable cost-aware engineering: You build the systems and attribution structures (tagging, showbacks) that give teams ownership of their impact.
Partner with Finance: Explain variances, maintain clean cost allocation, and help the business understand margins by product line.
no "spreadsheet purgatory": We don't want someone to just build dashboards that nobody looks at. We want you to build systems, write automation, and influence architecture.
high leverage: You'll have the mandate to partner with our most senior engineers on the "big rocks", like ClickHouse compression or Kafka partition strategies, where your insights have 7-figure impacts.
Direct impact: You’ll see the direct line between your work and our ability to lower prices for users.
If you’re tired of being the "cloud accountant" and want to be the "efficiency architect," we should talk.
Previous experience in FinOps, cloud cost management, or cloud governance: We’re looking for experts, not just "I looked at AWS bills sometimes"
Deep cloud fluency: You don't just know AWS/GCP are expensive; you understand the nuances of cross-AZ data transfer, NAT gateway costs, and the price-performance ratios of different instance families.
Kubernetes expertise: You understand how to allocate costs in K8s (which we know is notoriously hard).
the "hybrid" brain: You can speak SQL and CI/CD with engineers in the morning, then pivot to forecasting and margin analysis with the Finance Lead in the afternoon.
Bias for action: You’re able to write scripts to automate tagging hygiene rather than send a nagging Slack message.
CI/CD awareness: You understand how deployment patterns affect cost
Communication skills: You can explain cost insights to both engineers and finance without losing either audience
You don’t need to be a ClickHouse expert on day one. We’ll teach you the database internals, but you do need to enjoy owning complex infrastructure.
You’ve used tools like Vantage, CloudHealth, or Kubecost.
You have experience with our specific stack (ClickHouse, Kafka, Postgres).
You’ve used SQL for querying cost data
You have a strong opinion on when not to use Spot instances.
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