I built an AI growth engineer because I hated my analytics stack
We can vibecode a subscription app in days. Wiring up analytics takes weeks - every time.
Some time ago we at our studio decided to explore subscription apps. Our thoughts were - we can quickly vibecode and iterate over apps so that we can execute all the ideas we have and get apps up and running in days and weeks. Partially that was the truth, but not the whole one. Apart from App store review and everything we had to spend weeks on wiring up, setting up and getting data the way we wanted it to be.
RevenueCat for subscriptions, direct App Store webhooks, AppsFlyer for events and connections, Firebase for events and data, BigQuery with custom SQLs to process this, Meta Ads for ads. All of this needs to be wired up, all the events must be specified and put into the code and afterwards you somehow need to find answers to your questions across multiple systems each showing you a piece of the picture not the whole one. A few days of coding an app extended to a few weeks - the growth stack became bigger than the core functionality. Further, I had to start spending like 20-40 minutes every morning checking 4 different browser tabs, trying to understand why numbers are different in every one of them (as they naturally always are).
After some time of this exercise I asked myself - why can I ask Claude to code but should go and check dashboards with my bare hands? And that was the moment I started to think about a service - something that would wire all the events through my coding AI, get all the data and just answer my questions when I ask them.
As a result I created Pulse - AI growth engineer for subscription apps. I connected stores, Meta, Google Ads, RevenueCat and taught an AI to collect data, read it, calculate metrics and give me answers - in the app or in my coding buddy interface. What I am really proud of is how the calculations work. Ask an LLM for your MRR three times and you can get three different numbers. So in Pulse the AI never computes anything - a metrics layer works algorithmically in the background. AI is used to read and interpret it.
Here is a screenshot of what I asked about one of our apps and what I got just when I was writing this text. Note how it flags small samples and tells me not to act on thin data - that was one of my hard requirements while building this.
Right now Pulse is young and not yet as functional as I want it to be, however it is already working and working good it is. We have passed all the verifications (which is in itself a topic for another post - that was a pain). If you run a subscription app - I’ll connect it personally, no upfront costs, for just 20 minutes of feedback.
I hope this thing - pulse.pulsecircle.studio/?utm_source=indiehackers&utm_campaign=launch will be useful not only to us, but to a lot of AI-founders. I believe I am not the only one wasting time every morning to figure out what’s happening to my products. How much time does it eat from your mornings? And what could you have been doing otherwise?
Fair question, thank you!
I totally agree with the first part - metrics layer is indeed the defensible part. Reconciling stores, subscriptions and ads into something uniform is quite a job to do in itself, the chat is just a way into it.
As for the decisions it is quite early - it is currently mostly us using it with our own apps and some first testers. But I'd split the question in two.
Firstly - for simple questions like "what is my MRR" it is obviously the same answer, just faster to reach (I personally saved up to 30 minutes daily for four tabs I was checking every morning).
Secondly, the difference. I do not have enough evidence here just yet, but I do expect such things to happen on cross-source questions. Things like a campaign that looks dead in one tool because attribution is blind on that platform, while the platform's own signal is fine — or a metric drop that's actually a sync lag. Pulse already catches those in our data and explains them instead of just showing a number — whether that turns into different decisions is exactly what I want to measure.
Curious how you would define a "different decision" here - I'd like to start tracking it properly.