Quick Answer
PostHog got its first 1,000 users in about four months, from January to May 2020. The founders onboarded ten users by hand, widened into cold outreach, launched on Hacker News only once strangers could use the product without help, then added pricing and a hosted cloud version. The lesson for your company is the order: prove repeat use with a small group before you spend a launch on volume.
Most retellings of PostHog's early growth start at the Hacker News launch, because that's the part with a number attached. Three hundred deployments in a couple of days makes a satisfying story.
It is also the least transferable part. By the founders' own account, the launch went well mainly because the unglamorous steps came first, and those are the steps founders skip when they copy it.
Every figure here comes from PostHog's own writing: James Hawkins' post on how PostHog got its first 1,000 users and the company story in the PostHog handbook. This teardown covers the eight moves in the order PostHog made them, the product choices that made them easy, and the parts that only work with a Y Combinator batch or venture money behind you.
PostHog Reached 1,000 Users Four Months After It Started Building
PostHog was founded on January 23, 2020, and reached its first 1,000 users in May 2020, according to its handbook. Hawkins puts that at four months from when the team started building, during Y Combinator's W20 batch.
| When | What happened at PostHog | What it showed |
|---|---|---|
| Before 2020 | Five pivots, PostHog was the sixth idea | Ten committed users is hard |
| January 2020 | Founded on January 23, one-month plan begins | A deadline forces choices |
| February 2020 | Hacker News launch, 300 deployments in a couple of days | Strangers would try it |
| April 2020 | PostHog Cloud, two months after the launch | Growth improved sharply |
| May 2020 | First 1,000 users | Four months from building |
Read the dates as a sequence, not a speed record. Each step waited on evidence from the one before it, and the launch sits in the middle of the story rather than at the start.
One small discrepancy is worth knowing. Hawkins writes that the launch came five weeks after the team started building, while the handbook says four weeks after they started writing code, so treat "about a month" as the honest figure.
How PostHog Went From Ten Users to 1,000 Users
PostHog went from ten users to 1,000 through eight moves made in a fixed order, each one unlocked by evidence from the last. Hawkins is clear about which was hardest: getting the first ten users.
Each step below covers what PostHog did, how you'd run the same step, how to tell it worked and where it usually goes wrong.
1. Give the Idea One Month and a Pivot Clause
When the founders pivoted to PostHog, they wrote a one-month plan built around a single question. Did people dislike existing product analytics tools enough to try a new one, and could the team find out fast?
The plan carried its own consequence: if the founders missed its goals within the month, they would pivot again. They had already pivoted five times and found it very hard to get ten companies to use earlier products, so the clause was not theoretical.
To run it, write the question your month has to answer, the result that counts as a yes, and what you'll do on a no. PostHog's founders worked from 9am until somewhere between midnight and 3am, seven days a week, which is their pace and not the method.
It worked because the deadline forced decisions about what mattered, which Hawkins lists as his first lesson. The common mistake is a deadline with nothing attached to missing it, which is only a date.
2. Onboard the First Ten Users by Hand
PostHog's first ten users came mostly from the founders' personal networks, and none of them signed up alone. The team created accounts by manually editing the database and set people up over Slack, WhatsApp or in person.
Hawkins gives two reasons for starting with friends. It's the easiest way to find initial users, and building for a real person beats building for a hypothetical one, which surfaced edge cases the team would not have found alone.
To run this, pick people whose problem you understand and stay with them through setup. You'll know it worked when friends keep using the product and say it's useful, and the mistake is automating signup before you've watched a handful of setups break in different places.
3. Make Self-Serve Work Before You Ask Strangers
Once friends could use PostHog and found it useful, the team made it self-serve with a one-click Heroku deployment. Hawkins says plainly they knew it wasn't scalable, because the priority was validating the idea quickly.
The one-click deploy was a shortcut, not a system. It let a person the founders had never met get PostHog running without a call, which was the only thing the next stage needed.
Your version is the shortest path from interest to first value, even if it's held together by hand behind the scenes. The test is someone you've never met finishing setup without messaging you, and the mistake is polishing onboarding for a product nobody has come back to yet.
4. Widen Into Cold Outreach and Watch Who Returns
Next, Hawkins contacted more people he knew, then moved into cold outreach through groups he belonged to, introductions and LinkedIn messages. That took PostHog to a couple dozen users within a few weeks.
The count was not the point of this stage. The point was finding out if people the founders didn't know would use the product and keep coming back, which is exactly where their earlier ideas had failed.
Hawkins is blunt about what the answer means. "If people sign up but don’t come back over and over, you’ve probably found a valid problem, but not solved it."
His lessons add two working rules for the outreach itself: keep a meeting request to two or three sentences, and aim to reply within 30 seconds when someone answers. The mistake is counting signups, when the number that decides the next step is how many people returned without being asked.
5. Launch on Hacker News Only After Two Conditions Hold
PostHog's founders knew they were ready for Hacker News once users could sign up and use the product without help, and people they didn't know had signed up and found it useful. Both conditions describe behavior you can observe, not how finished the product feels.
PostHog launched in February 2020 as a self-hosted, open source product analytics tool under an MIT license. PostHog reached 300 deployments within a couple of days, and Hawkins credits that mainly to having done the earlier steps first.
The team also spent about $2,000 promoting the repository on Twitter, which together with the launch got it trending on GitHub. The handbook records more than 1,500 GitHub stars two weeks later.
After the launch-day bump, growth settled at a level noticeably higher than before, and that floor is the result to look for rather than the peak. The common mistake is launching to find out if anyone cares, when PostHog's two conditions had already answered that.
6. Ask Every New User How They Found You
The launch left PostHog with a steady trickle of word-of-mouth growth, so the team asked users how they heard about it, why they signed up and why someone had recommended it. They kept talking to existing users about what they liked, disliked and wanted solved.
Over a few weeks that produced a map of what users loved, how to scale it and anti-goals to avoid. It pointed PostHog toward features engineers wanted and also wanted to self-host, such as feature flags.
Put the same three questions into your onboarding call or first email reply. It worked if the answers cluster around a reason you can repeat, and the mistake is asking only the users who stayed.
7. Write About the Journey Instead of Selling
Around the same time, Hawkins started experimenting with content, since by his own account he isn't good at coding and could help that way. User conversations had told him developers wouldn't appreciate being sold to, so he wrote about the founders' pivots and moving to San Francisco for Y Combinator.
Those posts reached the Hacker News front page a couple more times, which proved the channel worked, so PostHog kept at it. This is content marketing for tech companies in its plainest form: the founder writes what happened, and the right readers find it.
Today the same writing also has to be found on Google and inside ChatGPT and Perplexity answers, which is the work an AI SEO service does on the pages themselves. Better Marketing runs this kind of founder-led writing on LinkedIn, X and Reddit for software founders who don't have the evenings to write it themselves.
It worked if new users mention the posts when you ask how they found you. The mistake is publishing product announcements and calling them a founder story.
8. Price Through a Calendar Before You Build Checkout
The launch gave PostHog the confidence to think about pricing, so Hawkins gauged interest in a paid offering with existing users and the Slack community. He also published a pricing page listing the paid features, with his calendar embedded so anyone interested could book a call.
Each call showed which features a buyer cared about and if they wanted to buy. Sales came more easily from new users arriving through the pricing page than from the existing community, which Hawkins suspects was because some users were there for the free product.
After a few weeks of trial and error, PostHog published a public pricing table and started taking card details, and every step toward self-serve raised the conversion rate. PostHog Cloud followed in April 2020 with a limited free tier, a 30-day free trial and no card required at signup, and the 1,000th user arrived a few weeks later in May.
It worked if calls start turning into payment without a custom negotiation each time. The mistake is assuming your free users will be your first buyers.
Five Product Decisions Made PostHog Easy to Try
PostHog's product choices were also distribution choices, because each one removed a reason for a developer to say no. Hawkins lists five, all made before the launch:
- Build for developers, because established product analytics competitors focused on product managers and selling to executives, and developers were an audience the founders understood.
- Focus on self-hosting, because developers cared about controlling their own data. Hawkins admits PostHog might have grown faster with a cloud product too, but self-hosting gave focus.
- Be open source and transparent, with a permissive MIT license to see if enterprises would use it, and a public company handbook.
- Make it easy to deploy, with event autocapture built into the SDKs so users didn't have to instrument every event by hand.
- Don't monetize at launch, because none of the multi-billion-dollar open source companies Hawkins researched had monetized in their first five years.
The fifth decision carries the most conditions. PostHog was venture-funded and entering a crowded market with competitors at around $100m in revenue, so Hawkins was confident monetization would come later, and he writes that it isn't universally good advice.
What Transfers From PostHog to Your First Customers
The sequence transfers to almost any software company, while the specific tactics transfer only when your conditions match PostHog's. The table sets each PostHog condition against what you can borrow and what you can't.
| PostHog's condition | What transfers | What does not |
|---|---|---|
| Venture-funded, validated category | Delay pricing while learning is the goal | Waiting years to charge |
| Developer audience | Remove setup friction where your buyer works | Expecting non-technical buyers to self-host |
| Y Combinator W20 batch | Launch once strangers succeed alone | Guaranteed front-page placement |
| Founder willing to write | Write what happened, not what you sell | Midnight hours as the operating model |
The part that transfers everywhere is the order: repeat use first, then reach, then revenue. Peec AI ran its own version of that order with letters of intent on a prototype, and the first-ten stage is broken down step by step in how to get your first 10 customers.
Founder writing is the most portable tactic on the list. It's where most content marketing for tech companies should begin, and an AI SEO service keeps those posts findable once buyers ask ChatGPT as often as they read Hacker News.
The order also sets the right moment for outside help. A B2B demand generation agency does its best work once there is a product people come back to, because outreach then converts warm trust into customers instead of feeding a product nobody keeps using.
Where the PostHog Launch Playbook Does Not Apply
PostHog's launch is the part of its story least likely to work the same way for you. Several of its advantages were structural, and copying the tactic without the structure produces the spike without the floor.
- A front-page launch is a Y Combinator benefit. The Hacker News FAQ lists startup launches among the features the site gives YC companies, and those launches get placed on the front page.
- A Show HN, the route open to everyone else, has its own rules. The Show HN guidelines require something people can try, rule out sign-up pages, and forbid asking friends to upvote or comment.
- Deferring revenue was affordable because PostHog was venture-backed in a validated market. Hawkins writes that in a new market, a worse fundraising climate or a bootstrapped company, monetizing sooner would have mattered.
- Self-hosting and autocapture fit developers who install things themselves. A buyer who needs procurement, security review or a sales call won't behave like a developer trying a Heroku button.
The bad practice worth naming is the launch-day ring of friends asked to upvote, which Hacker News explicitly prohibits and which proves nothing about repeat use. If your product can't yet pass PostHog's two conditions, a bigger launch only exposes that faster.
Copy the PostHog Order Before You Copy the Launch
Pick a one-month question, onboard a handful of users by hand, and don't launch until strangers can succeed alone and come back. Then ask how people found you, write about what happened, and price through conversations before you build checkout.
That order is what PostHog got right, and it matches how developers discover tools today: through trust built in public before any pitch. When your product has earned repeat use, Better Marketing works as a B2B demand generation agency that turns that warm trust into your first customers, without ads.