I Set Up Product Analytics in 3 Days With Zero Budget. Here's the Stack I Actually Used.

The problem: you need answers tomorrow, not next quarter

When I joined Sonic Linker's founding team, we had a working AI product and early users. What we didn't have was any clue what those users were actually doing.

Were they using the core AI feature or just poking around? Where were they dropping off? Which features justified charging money?

I needed answers in days, not weeks. We didn't have a data engineer. Our budget for tools was basically zero. And I still had to ship features every week, so I couldn't spend a month setting up infrastructure.

This is the reality for most early stage teams. You need data to make decisions, but you don't have the resources that let you build a proper data warehouse. Here's what I actually did.

The stack: three tools, zero engineering dependency

I picked PostHog as the core analytics platform. Self-hosted option meant free for our volume. The key thing was that it handled both event tracking and session replay in one tool. I could see the numbers and then watch what actually happened.

For the implementation, I worked directly with our frontend dev to add the PostHog snippet and set up event tracking. We started with just five core events: signup, first AI generation, second generation, feature discovery, and export. That's it. No complex taxonomy, no 40-event tracking plan. Just the minimum to answer: are people getting value?

I added Google Sheets as my analysis layer. Sounds ridiculous, but here's why it worked. PostHog let me export cohort data and funnels as CSVs. I pulled that into Sheets, built simple pivot tables, and suddenly I had weekly active user trends, feature adoption rates, and retention curves. The CEO could open a Sheet and see the numbers. No learning curve, no dashboard access issues.

The third piece was Hotjar for heatmaps, but honestly, I barely used it. Session replay in PostHog was enough. I could watch 10 sessions and spot UI confusion faster than any heatmap.

What I learned: start with questions, not events

The biggest mistake I see PMs make is starting with "what should we track?" Wrong question.

I started with: what decision do I need to make this week?

Week one, the decision was whether to prioritize improving the AI model or building a collaboration feature. So I tracked: how many users generated content more than once? If they weren't coming back for a second generation, the model wasn't good enough. No collaboration feature would fix that.

Turned out 38% of users who generated once came back for a second try within 48 hours. Not great, but enough signal that the core loop worked for some segment. We focused on understanding that 38%, not building new features for the 62% who bounced.

At Finvestfx, I used the same approach with enterprise clients. We had 20+ treasury teams using our platform, but no idea which features justified renewal. I set up event tracking in Mixpanel (they had budget, unlike Sonic) focused entirely on actions that saved time: bulk uploads, automated reconciliation, export to their ERP.

Within two weeks, I had data showing that teams who used bulk upload in their first week had 90% retention after six months. Teams who didn't? 40%. That one insight changed our onboarding. We made bulk upload mandatory in the setup flow. Retention jumped.

The parts that actually take time (and the shortcuts)

Setting up the tool is easy. The hard part is defining what matters.

I spent half a day just writing down every question I had about user behavior. Then I grouped them into three buckets: activation (are they getting initial value?), engagement (are they coming back?), and monetization (would they pay for this?).

For each bucket, I picked one primary metric. Activation was "second AI generation within 48 hours." Engagement was "active three days in a week." Monetization was "used a premium-only feature." Three numbers. I could check them every Monday in 10 minutes.

The shortcut I wish I'd taken earlier: don't wait for perfect data quality. I spent a week arguing with the dev about event naming conventions and whether we should track button clicks or intent actions. Wasted time. We shipped tracking with inconsistent naming, and I cleaned it up later in my SQL queries. Getting directional data in three days beats getting perfect data in three weeks.

What this actually gets you

This setup won't give you a fancy data warehouse or real-time dashboards. But it will answer the questions that matter when you're pre-product-market fit:

• Which features are people actually using?
• Where are they getting stuck?
• What separates retained users from churned users?
• Is this new feature moving the core metrics?

At Sonic Linker, this system supported decisions through our first six months of rapid iteration. We shipped the core product in three months because we could validate (or kill) features in days, not weeks.

You don't need a data engineer to get started. You need clear questions and the discipline to track only what answers them. Start there. Add complexity when you've earned it with traction.