# Reverse Engineering a PostHog SuperDay

DevFeed: [Reverse Engineering a PostHog SuperDay](<https://devfeed.tech/articles/reverse-engineering-a-posthog-superday-32359.md>)

Original publisher: [Read original article](<https://joshtronic.com/2026/08/09/reverse-engineering-posthog-superday/>)

Author: Josh Sherman

Published: 2026-08-09T00:00:00Z

Content type: opinion

Language: en

Sources: [Josh Sherman](<https://devfeed.tech/sources/josh-sherman.md>)

Topics: [Reverse Engineering](<https://devfeed.tech/topics/reverse-engineering.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [Software](<https://devfeed.tech/topics/software.md>)

Tags: [engineering](<https://devfeed.tech/tags/engineering.md>), [open-source-software](<https://devfeed.tech/tags/open-source-software.md>), [oss](<https://devfeed.tech/tags/oss.md>), [reverse-engineering](<https://devfeed.tech/tags/reverse-engineering.md>)

## AI overview

The author describes examining PostHog's onboarding wizard and open-source repositories while trying to understand whether certain issues and pull requests were connected to potential candidates. The author remains uncertain about this theory but found the core team's constructive feedback notable.

## Source excerpt

I'm not here to bullshit anybody, I have never been through a PostHog SuperDay. Like many humans, I've read about it on their website, as they are a company that over-communicates just about everything. This tale started when I got curious about their onboarding wizard. Their pivot from analytics to self-driving systems mirrors what I've been working on for the last couple of years, which has accelerated greatly over the last 3 months. Figured there was probably something I could learn and possibly bite off to include in my own system. Figuring out what to do I've been around open source software (OSS) for a good long while now. Even though I've had some strong opinions about the state of things over the years, I still believe it's the way. If not for OSS, I wouldn't be able to say things like "I wrote a Lorem Ipsum generator that's somehow been installed over 1 million times." These days, most projects have a label on their issues that indicate what's good for a new contributor to pick on. PostHog's repos are no different, except the repo I was looking at didn't have any issues tagged with the good first issue tag. Not a big deal, with 100+ open issues I figured I'd be able to find something I could pick up to give me a chance to play with the codebase. I did find a handful of things, I even started to chase down one of them. As I did I realized I kept talking myself out of each issue because what appeared to be low hanging fruit was stuff that I could defend deprioritizing. A pattern started to emerge Along this journey of trying to find an issue worth fighting for, I started to notice a pattern of somewhat disparate issues and PRs opened by the same contributor. I also noticed that core team members (read: employees) were commenting on these issues and PRs and not in the usual "yea or nay" fashion that I see. The comments were constructive in a way that you'd be with a more junior teammate that you're attempting to mentor and train up. Not a bad thing, but the fe