PostHog ships every two weeks, unless it makes more sense not to.

Iterating frequently helps improve our product. We get features in users’ hands as soon as possible, even when those features have bugs or are very basic.

Many new features are so simple they can verge on embarrassing. That’s how they should feel when they’re launched to the first users, if you have a forgiving initial audience. If you don’t have one of those, you should find one (and use feature flags!)

This gives us a quick sense of what users really need. It’s better to spend a week building something and learning no one cares rather than losing a month polishing the wheels on the moon-buggy when it turns out that Earth is pretty cool anyway.

You can learn more about what people need from what they do rather than what they say.

We find very frequent updates for important software annoying to update constantly… I'm looking at you, various wordpress plugins!

The tradeoff is "is this new bundle of features useful enough to outweigh the time spent upgrading at this point in time". If we have a feature we believe is particularly useful and it was only a week since the last update, we will ship it.

Self-deploy aside, there are challenges with frequent shipping in SAAS too. Users have to get used to new functionality. We think it's easier to adapt to frequent tiny changes rather than huge overhauls of the UX. Some may disagree!

Some features are too big to get into a releasable state every week or two. Often our team are very excited about something we are building and we really believe it could help our users. If it’s good enough, and could help us learn a lot, it doesn't make sense to delay it to the next cycle. Instead, we’d ship the update a couple of days later.

If we set hard deadlines for shipping a huge new feature, we’d be up all night involuntarily, and we’d not be able to retain a diverse team - it’d mean only those able to do this repeatedly would choose to stay working with us.

One rule we try to stick to is one pull request per developer per day. That can sometimes mean a Work In Progress, but it always means something goes into the repo.

Pull Requests that take longer than a day often spiral into weeks - and people like helping… getting visibility into what you’re doing makes that possible. Getting out of a rut starts with accepting that you’re in one!

As we grow and create non technical roles, we'll look to apply this principle there too. You can see this from the way we've rebranded our website if you follow the posthog.com repo.

If we keep our team first, customers and users second, then our investors will take care of themselves!

We have deliberately not sought enterprise customers early on for this reason. The stronger we can get our product and engineering culture before this happens, the better a position we will be in before having to change anything.

For now, we solve this in two ways for bigger enterprises: (i) you don't have to update so frequently, although that will mean many new features suddenly appearing in one go OR (ii) we offer maintenance of your deployment as a paid service.