james_impliu

PostHog | Full-Time | Product engineers, Technical CSMs, Technical AEs | REMOTE (all remote) | Hiring GMT-8 to GMT+2 PostHog makes dev tools that help product engineers build successful products.

* we have a public handbook (posthog.com/handbook) if you want to learn how we work, pay and more in complete detail.

* we are growing through more autonomy and transparency not through process.

* we have a ton of scale and a bunch of super interesting technical problems to solve

* we're building 20 more products over the next couple of years, so you could end up building one of those

* public compensation calculator! see immediately what you'd get paid

* we're hiring: product engineers, clickhouse operations engineer, backend engineers, technical customer success managers, technical account executives, developer marketers, bdr team lead, rev ops manager, and more.

https://posthog.com/careers

PostHog | Full-Time | Product engineers, Technical CSMs, Forward deployed engineers | REMOTE (all remote) | Hiring GMT-8 to GMT+2 PostHog makes dev tools that help product engineers build successful products.

* we have a public handbook (posthog.com/handbook) if you want to learn how we work, pay and more in complete detail.

* we are growing through more autonomy and transparency not through process.

* we have a ton of scale and a bunch of super interesting technical problems to solve

* we're building 20 more products over the next couple of years, so you could end up building one of those

* public compensation calculator! see immediately what you'd get paid

* we're hiring: product engineers, clickhouse operations engineer, backend engineers, technical customer success managers, technical account managers, developer marketers, forward deployed engineers and onboarding engineers.

https://posthog.com/careers

PostHog | Full-Time | Product engineers, backend engineers, Technical AMs | REMOTE (all remote) | Hiring GMT-8 to GMT+2

PostHog equips developers to build successful products by combining product analytics, feature flags, session replay, a data warehouse, CDP and many more.

* we have a public handbook (posthog.com/handbook) if you want to learn how we work, pay and more in complete detail.

* we are growing through more autonomy and transparency not through process.

* we have a ton of scale and a bunch of super interesting technical problems to solve

* we're building 20 more products over the next couple of years, so you could end up building one of those

* public compensation calculator! see immediately what you'd get paid

* we're hiring: product engineers, clickhouse operations engineer, incident response engineer, product managers, technical account managers and technical customer success managers.

https://posthog.com/careers

i can remember a discussion with Cory (who built this with Eli, the front end eng) on the topic of "why do all websites consist of a collection of long scroll-y pages / is that appropriate for our business?" and we concluded it wasn't optimal.

at the time, we were trying to figure out how to add more products in without it becoming messy, and we concluded we're trying to do a lot more than just what would work well for a 1 product company (we have very extensive content for example) - we feel quite multidimensional. thus a flatter design was proving hard to do. we wanted something that could enable us to offer a very wide variety of things (like 10+ products, handbook, job board, newsletter etc)

a lot of existing websites are trying to convey what they do in <3 seconds, and all of the internet is going for that. our company doesn't fit into 3 seconds, or if it does it's annoyingly vague "a whole bunch of devtools"...! so we thought hey we'll do something that means people _will_ explore and learn what we do better. it will mean _some_ people bounce and that's ok, because those that stick will (sometimes!) love it.

as a project, it looked fun and we knew it'd stand out a lot as a way to justify it. it's much nicer and more cost effective for us to ship something 10/10 cool than go down the outbound-y sales route. we run at a 3 month cac payback period if you're into startup stats. the proviso is that only works if you go _really_ deep, so that your work actually stands out.

PostHog | Full-Time | product engineer, technical founder engineers, backend leaning full stack engineer | REMOTE (all remote) | Hiring GMT-8 to GMT+1

PostHog helps engineers build better products by combining product analytics, feature flags, session replay, a data warehouse, CDP and many more.

* open source, building a dev tool. We have a public handbook (posthog.com/handbook) if you want to learn how we work, pay and more in complete detail.

* we are a real business... nearly at $20M ARR / profitability in sight / lots of capital / grew revenue 4x last year but only added 3 people / just had first cashflow positive month in October this year!

* you decide what to build, and iterate with your users - we are growing through autonomy and transparency not through process.

* we have a ton of scale and a bunch of super interesting technical problems to solve

* we're building 50 more products over the next couple of years, so you could end up building one of those

* we need: product engineer, technical founder engineers, backend leaning full stack engineer

posthog.com/careers

hey (founder here), that shouldn't be happening, although this can take us some time (we get thousands of applications, although HN is a very high quality source) - could you email me james at our website.com? i'll double check what's going on.

Ah definitely email me then! If you are full stack but lean heavily front end and love taking pride in your craft / like working reactively based on what you think needs prioritising vs a more process oriented approach please email me!

PostHog | Full time | Remote (West coast US to central europe timezones) | https://posthog.com/careers

We're an all remote company of just 50 with 8 products and significantly >$10M ARR. All inbound, no sales team. 70k companies have installed our software, 1,600 new companies install each week. Shipping tools to help developers build successful products.

We quadrupled our revenue, only added 3 people net last year, and now expanding as a result. We work in small teams, who fully own each product. Our engineers decide _what_ they will work on, not just _how_ to ship things.

See how our entire company works in a ton of detail at posthog.com/handbook, including how much we pay!

Hiring product engineers, a technical support engineer, a UX engineer, a distributed systems engineer, a site reliability engineer, and a community manager.

Please apply through our careers page on our website, or enter my email inbox lottery (james at you can guess it), but i would recommend the former!

(Founder) wanted to explain our intent behind the business… so here’s the origin story.

We tried to make the business work exclusively with self hosted and open source focus. I thought cloud would never work as we have so much competition. However we just couldn’t make hosting it at scale a good experience. We often have more data than customers production instances.

We wound up having to spend a ton of time debugging k8s in other people’s infra via screenshots. This wasn’t good for us or customers.

We kept having people hosting it themselves for no reason other than liking us so for the sake of a good experience for them, we made a cloud product. This represented the majority of users. It’s also cheaper for most people as we just have a big free tier and shared infra costs, so no hosting bill. Turns out cloud worked.

We didn’t want to abandon the OS project but we stopped trying to make money via an open core model. That means we call it a hobby instance because it just doesn’t scale very well.

you wouldn't have posted this if you didn't already know it's not going to work out!

yep - on the grounds we have lots of competition so we need to stand out! And hey, front page HN for doing weird stuff… :)

(Founder) we wanted to be able to capture questions on each page of our docs - so someone learning about our JS SDK (for example) could see questions about it under the main docs content, to try to avoid people missing gotchas.

In general we invest a ton in the website as we don’t do sales - it is our sales team!

And in future we anticipated building ie merch rewards for people that answer questions, people about to submit blog posts and stuff all through the same login… community based things. This is all pie in sky at moment but we’re going to experiment with it.

Ah it's my company's operating handbook not our product docs or marketing pages. Didn't expect to see this here so fast after we rewrote it recently!

Regardless, I've made a PR to tighten up one of the titles that is confusing here, waiting on build :) https://github.com/PostHog/posthog.com/pull/6862

we mainly do this because it can just help with getting PRs approved if we want to fix an issue in something we rely on (and it is nice / we can list as a perk), and a little influence can be very valuable if we want to give feedback on a project's direction. doesn't do much on the growth side as far as i'm aware, for us at least.

Yikes, I'm the founder of this company (one of my colleagues wrote this piece) - just saw it appear here. We shipped a rather huge change to the website recently (we're trying to let other people post stuff too), think we accidentally made it janky and missed this. Will fix when the right person wakes up - he's west coast US! Sorry for QA via HN :)

ok that is fair - going to SF frequently but not living there is something i should have been clearer on!

my cofounder and i go 3-4 x a year now, for 1 week at a time. it acts like an offsite - get out of usual routine, meet interesting people, do lots of meetings (we'd normally avoid this sort of thing), get ideas and up our ambition, then go home and build stuff for 3 months quietly. repeat!

in the early days, if you fundraise, then at least SF based firms are way better to deal with in general, of course with many exceptions

1. Just be yourself, proudly. Some people _will_ hate it, others will love it. Getting product market fit is so damned hard, you are way better off looking for a smaller number of people that love you.

2. I'd shoot for 5 reference customers (paying list price, using it as you'd expect and genuinely delighted). Along the way I'd track who you try to sell to in a spreadsheet (including those that just drag on and never close) and I'd score them across the behaviors/things you would expect your target audience would have in common. This will help you create an Ideal Customer Profile - which you can then target more and more heavily (where you do marketing / what you build next and so on in future). Be _very_ specific not just ie by industry. For example, paypal targeted ebay power sellers in the early days.

3. Absolutely not. I've more than 40K customers at my startup and I live in a village no one has heard of in the UK.

4. Don't worry about scaling up via marketing until you have 5 reference customers (and generally do more of what got you the first 5 as your first step)

5. Read Secrets of Sandhill Road to understand the VC model more deeply. If you bootstrap - you have total control, might make more if you sell (because of how preferred shares work) but it will probably cause you more personal financial stress. Decide what motivates you - lifestyle business or trying to build a $10bn company. VC is an irreversible door, more or less, whereas bootstrapping isn't. I'd default with bootstrapping if unsure.

PostHog | Full-Time | Distributed systems engineer (and lead), full stack and ex technical founder engineers | Remote (all remote) | Hiring GMT-8 to GMT+1

PostHog helps engineers build better products. we launched on HN during a YC batch in 2020 and have been growing very fast ever since.

* open source, building a dev tool. We have a public handbook (posthog.com/handbook) if you want to learn how we work, pay and more in complete detail.

* we are a real business... nearly at $10M ARR / profitability in sight / lots of capital

* we are growing through more autonomy and transparency not through process.

* we are under a ton of pipeline pressure due to how much we've grown usage (~5x per year at the moment) - we need help rewriting our ingestion for the next 2 years of scale whilst dealing with 1 million events/minute being ingested. this will be very hard, but it is the _biggest_ challenge our company faces. revenue and growth are coming easily.

* goal is to build a company worth $10s of billions, by building wide first (we are the all in one platform with lots of tools) then going upmarket way later (similar product and go to market to Atlassian). we grow entirely through word of mouth and content marketing, not from outbound sales.

* we need: a distributed systems engineer to lead our pipeline team, 1-3 other individuals to work in the same team. you'll be working alongside experienced people who've worked at places like datadog/meta/twitter in this small team (currently 3 people).

* we are also hiring: ex technical founders and front-end oriented full stack engineers!

I feel like a weird industry has popped up that makes you feel like you can validate everything in advance. I think this comes from Product Managers in large, risk-averse companies that excessively try to minimize mistakes.

However, if you want to start a startup, you aren't optimizing for mistake minimization! You are figuring out if anyone cares as quickly as possible. You will only get true validation of this by seeing if people use your thing, and then iterating from there.

My advice would be - you have to _both_ talk to people and _at the same time_ create whatever your MVP is to launch as fast as possible. It might be a spreadsheet. It might be you doing stuff manually for them before building the software. Get something into their hands as quickly as possible.

the former - we've gone anywhere from $0 to about $40k/month, averaging somewhere in the middle

PostHog | Remote GMT -8 to +2 | (i) Technical Writer (ii) Senior Developer | Full Time | Salaries all visible at posthog.com/handbook/compensation (location-dependent)

https://posthog.com - see handbook at posthog.com/handbook

Open source, 6x rev growth last year, heading for profitability soon, well paid experienced team of 37 today, 25k customers across free + paid products, 65k developers in community, 0 outbound sales - all inbound growth. Didn't raise a 2021 overpriced round - real (potential!) upside.

* Technical writer *

Looking to hire a developer who loves to write. We aim for each piece we produce to be the best on the internet for that topic.

Content marketing is huge for us - writing deep technical content is what we want! You'd be on our (small) marketing team, making a huge impact.

Previous blogging (especially personal/interesting!) and a few years of development experience needed.

If interested, james at posthog.com and charles at posthog.com for a chat.

* Full stack developer *

We are looking for someone to build the next generation of our analytics backbone. You'll be working on ClickHouse and Python to make sure all our queries are web scale and users are happy.

You will (probably) help us build HogQL https://github.com/PostHog/meta/issues/86 (our own wrapper around ClickHouse SQL), or whatever else you think makes sense to prioritize. We work in small teams of up to 6, and you'll have a lot of trust to pick what to work on.

You need experience building high performance data systems, must be an expert at Django with deep SQL/database skills. Ideally, but optionally, you'd have worked in a high growth SaaS company / analytics product and have extensive experience with TypeScript-based React. We need someone ideally that has both worked in a very scrappy / early stage way _and_ ideally has seen a company scale.

This work will potentially extend into providing a full warehouse to our customers. It's a chance to work on the next Snowflake, but open source and product led, working with new companies from day 1 and staying with them as they scale - so get here in the first 40 employees before we are 100x the size.

If interested, james at posthog.com + careers at posthog.com and please mention you saw us on HN.

I work at PostHog, but didn't write the article. I'm guessing what we meant here is that we use a small, flexible agency that manages our paid ads. We didn't want any "optimized" landing pages or other stuff, we just wanted _any_ spend here to go on generating some relevant traffic (since often we think conversion rate optimization is harmful for brand/word of mouth, especically with a technical audience who in the long run respect companies that give you all the info up front etc, and we can do the other bits like SEO research).

We spend $5k/month with them + give them a monthly spend to do 99% of the work so we don't try to build any paid ads core competency in house. Continuously we've been trying to move spending from here to more organic content, and just leaving spend on the highest conversion paid campaigns (like our own brand name... which sounds stupid but it is broadly accepted as cost effective to boost CTRs for high intent traffic on Google's first page).

This is really impressive work. I’m the founder of posthog - James at you can guess it dot com. If you decide to get a dev job, and you think you’d learn a lot here, happy to chat!

hey, I wrote this piece and realised it was here! to respond to a few of these points...

What do you plan to do if you run out of your current money without being profitable yet?

We maintain default alive status (there's a good Paul Graham essay on this), and visit our growth assumptions every couple of months so that we can track to profitability. We give ourselves a $4M cushion - ie our expected low point in capital before hitting profitability (last round was $15M to give a sense), which is a fairly conservative. Worst case scenario is that if this fails, our revenue has already grown a ton since our last fundraise.

But once growths slows you'll probably get to know that side of them

Fair point. I guess it's less important but still not great though if you are able to get to default alive/profitable and if you've got good terms through the first couple of rounds.

(Founder)

To be blunt, we cannot guarantee not sharing data in the scenario that the US government forces us to transfer data to them from our EU Cloud. We have self hosting for those who want 100% certainty of GDPR compliance, as then we require no access to the instance.

The case law[0] as it stands today makes it impossible for US companies to fully comply in practice if providing cloud software like this - in order to comply with a request from a US agency to transfer data out of the EU, a US company would need to breach its obligations under GDPR today (and vice versa). However, recent changes[1] in the US may (or may not) enable legitimate transfers from the EU to US, but a ruling from the European Commission on this isn't expected until 2023. For this reason, we've launched PostHog Cloud EU on AWS in Frankfurt for now (we've had many customers asking for this) as a first step. From here, we can iterate depending on the above or by changing our legal structure if we wind up with a ton of adoption and want to improve this offering.

We'll issue a few clarifications to the page and docs to help explain the above properly, as I think we should make the above points more clearly on our website. We didn't expect this to appear on HN front page so fast!

[0] https://noyb.eu/en/project/eu-us-transfers [1] https://noyb.eu/en/new-us-executive-order-unlikely-satisfy-e...

(Ironically it might be an ad blocker in your browser causing this!)

At PostHog we've hired a bunch of people like this.

One word of caution - sometimes we get a contribution from people right ahead of applying for a job. The best applicants are ones who are existing users and who really are interested in the product, versus those who are doing a pull request to stand out. The latter is still a positive, but the former (depending on the quality of PRs!) is the home run!

It's because we wanted our team to be aware that we'd have this intention so we don't miss out! If someone leaves PostHog voluntarily to start a new company (i) that's sad for us but is a pretty cool reason to leave and (ii) if we were willing to employ them, we'd be willing to invest in them more.

There are some pieces of missing context I guess. Primarily that we're small still (30 people) so we tend to hire a lot of ex founder / generalist type people (and most are technical) who'd be quite well suited as founders.

One thing I will do is add a more detailed handbook entry to create more clarity around this benefit so we don't mislead/confuse. Issue made (https://github.com/PostHog/posthog.com/issues/4013)!

(I’m a cofounder there)

You are correct - haven’t actually done this yet since we’ve had no chance to so don’t take too much from this policy until we’ve done it a few times!

We set up hedgehog.vc which is what we’d use to fund ex employees if you’re curious.

For small sites there's a hobby deployment (https://posthog.com/docs/self-host/deploy/hobby) that costs $10/month to host (we can't get it below that at the moment), or we give a lot of free usage away on cloud for smaller sites. I'd stress we're product focussed (product analytics + session recording + feature flags + experiments), and plausible is web analytics (Google Analytics alternative), so choose accordingly!