“Oh but Adam!! I vibe coded an app in a weekend that makes monkeys dance all over your instagram feed and it’s already been downloaded 1 million times and I have an ARR of $300,000”
Ok sure, there will always be a few exceptions, but for the vast majority of us this is just not going to happen.
Do you know why?
That’s not how software works.
In software, you start with an idea. You build your idea. You throw it out into the wild. It gets used. It gets used in ways you expected and ways you never expected. Users give feedback. Users ask for features. You iterate. It breaks. You iterate again. You improve. You refactor. You hit scaling issues (if you’re lucky). You iterate again. And on and on and on.
This is why Observability is so crucial. One tool that has really helped me with Observability is Posthog.
I want to share with you 3 features of Posthog that have changed the way I develop. I use this tool both in my professional and personal projects.
Lets get started.
Session Replays
This is probably the most valuable feature on Posthog for me. Prior to this feature I was wandering around blindly. I had no way of knowing how my users were really interacting with the apps I was building.
Tracking events — button clicks, scrolls etc (and we’ll get to that) — is good but they only give you points along a path. They don’t show you how the user actually travelled along the path. This is where session replays come in.
I have lost count of the amount of times that session replays have helped solve a bug or triggered a change in a feature. It’s a game changer.
Error Tracking
Error tracking basically does what you would expect. It tracks errors. Posthog’s implementation isn’t quite to the level of Sentry but it’s still good. It records errors and then shows them on a dashboard where you can find metadata and even session replays when the error happened.
Tracking of error over time
It tracks the same errors over time so you can find out which errors are the most frequent.
Logs
Any modern web app these days needs a backend. One could argue your backend is more important than your frontend in this day and age with the value that data provides.
There are a wealth of possibilities when it comes to deployment these days but on most of the platforms I have tried, the default logging UX is not the best. Whether its AWS, Laravel Cloud, Argo etc, they all have logging but their implementations are all quite basic.
I‘ve been using Posthog Logs on one of our apps at work and its proving really useful. Just being able to filter the logs by type — ‘info, error, warning’ — has proven so useful.
Press enter or click to view image in full sizeExample of Posthog logging in action
Being able to quickly filter logs to find the exact one you’re looking for is a real advantage when working in an environment that needs to iterate quickly whilst keeping up time above 99.9%.
Events & Dashboards
Events are the building block of analytics and observability. You want to know if a user clicks a button or inputs something in a certain field then events are there for you.
They’re great for giving you a “state of the world” at a glance. Creating events and then setting up insights in a dashboard can really help you understand the usage of your app at a global level.
Conclusion
For the longest time I was using Google Analytics for gaining understanding of how users were interacting with my applications. However, I can see now that since using Posthog, Google Analytics is really restrictive.
The additional features from Posthog such as Session Replays, Logging and Error tracking really add value and enable you to focus quickly on the painpoints and frustrations you users are feeling when using your app.
In an ideal world you would have a constant stream of really clear feedback directly from the users telling you exactly what is wrong and what they would like to see in the future. Posthog offers the next best thing to that.
If you have a live app and you are thinking what observability tool to use, I really recommend trying out Posthog.
