Working with the website team

The website is owned by Cory Watilo and Eli Kinsey. For general questions or quick updates, the best place to start is the #posthogdotcom Slack channel.

For most pieces of work, like blog posts and copy updates, you can ship without needing a review from the website team. However, for larger pieces of work — a new product page, a significant copy overhaul, a new landing page — there's a more structured process to follow.

Why can't I vibecode? You can, but vibecoded stuff tends to be harder for the website team to review and has a tendency to not work well with some existing systems.

Requesting large website changes

1. Draft the content in a Google Doc

Start with words, not designs. Write out the full copy, structure, and any specific requirements. This gives the website team something concrete to work from, and keeps early-stage feedback focused on what matters: the message.

2. Submit it to the website team as a GitHub issue

Open an issue in the posthog.com repo using the Website Request template and link your Google Doc. Include:

• A brief description of what you're trying to achieve and why
• A link to your Google Doc
• Any relevant context or references
• Your timeline and deadline, if there is one

3. The website team builds from that and opens a PR

Once the issue is picked up, the website team will build the page. They'll open a PR and tag you when it's ready for review so you can give feedback on changes.

4. Review and give feedback from the PR

Review the PR, leave comments, and iterate from there. This is the right moment to give design and layout feedback — not before, when things are still just ideas.

Why this process

This approach is designed to stop time being spent on designs that don't get used. It also keeps the dynamic clear: the PMM team hands off, the website team builds, and everyone can feedback.

We don't want to overbake or complicate this process. This is as simple as it can be and as complex as it needs to be.