All Writing
๐Ÿ“Š Data & DecisionsDeep DiveSeptember 20264 min read

I Set Up Analytics That Actually Got Used in 2 Days. Here's the Stack and Why It Worked.

At Sonic Linker, we had no data engineer, no budget for fancy tools, and a product that needed instrumentation yesterday. I cobbled together a system using free tiers and one weekend. Two years later, it's still running and founders still ping me asking how we did it.

When I joined Sonic Linker's founding team, we had a problem. We were building an AI SaaS platform and shipping fast, but we had zero visibility into what users were actually doing. No data engineer. No budget for Amplitude or Mixpanel's paid tiers. And honestly, no time to wait for someone to build a perfect data warehouse.

I needed something up in 48 hours that would answer basic questions: Are people using the feature we just shipped? Where are they dropping off? Which accounts are actually active vs. just signed up and ghosted?

Here's what I did, and more importantly, why it actually worked when most early-stage analytics setups become shelfware.

The Stack: Boring Tools, Smart Setup

I went with PostHog (self-hosted, free tier), Supabase for our database (we were already using it), and Google Sheets for the stuff that needed to be dead simple.

PostHog handled event tracking. I set up maybe 10 core events: sign up, project created, AI query run, export clicked, that kind of thing. Not 50 events. Not "track everything and figure it out later." Just the events that mapped to our actual user journey.

Supabase gave us raw data access. I wrote basic SQL queries to pull cohort data, calculate weekly actives, and track feature adoption by account. Saved those queries as views so anyone on the team could run them without asking me.

Google Sheets was for the manual stuff early on. Weekly retention cohorts, enterprise client health scores, NPS follow-ups. I know, I know, sheets aren't "real analytics." But they're fast, everyone understands them, and they force you to think about what actually matters instead of building dashboards nobody looks at.

Why This Worked When Most Setups Don't

I instrumented backwards from decisions, not features.

Most PMs instrument everything because they're scared of missing something. So you end up with 100 events, dashboards that take 10 seconds to load, and nobody actually uses any of it.

I started with three questions we needed to answer every Monday: 1. Which accounts are actively using the product this week? 2. Are new users completing their first successful action within 24 hours? 3. Is the feature we shipped last week getting adopted or ignored?

That's it. I set up events and queries to answer those three questions. When we needed to answer a new question, I added instrumentation for that. Not before.

I made it stupid easy for non-technical people to get answers.

At Finvestfx, I watched a beautiful Looker setup die because only the CTO could write queries. At Sonic Linker, I made sure our founder could pull weekly actives without pinging me.

I documented every query. I created Slack shortcuts that posted key metrics every Monday morning. I made sure the PostHog dashboards had big numbers at the top, not 12 line graphs that required a statistics degree to interpret.

If your analytics setup requires you to be the gatekeeper, it's not a setup. It's a bottleneck with your name on it.

I didn't wait for perfection.

Our event naming was inconsistent for the first month. Some events fired twice. Our retention calculation was rough. And you know what? It was fine.

We caught the big stuff: a feature we thought was crushing it had a 12% adoption rate. A flow we assumed was smooth had a 60% drop-off at step two. An enterprise client we thought was thriving hadn't logged in for 11 days.

You don't need perfect data. You need directionally correct data that you actually look at and act on.

What I'd Do Differently Now

I'd set up better event taxonomy from day one. We spent weeks later renaming events and fixing inconsistencies because I was lazy early on. Worth the extra two hours upfront.

I'd also instrument error states better. We tracked successful actions but not failed API calls or broken user flows. That bit us when we had a bug that silently failed for a week before someone complained.

And I'd push harder on getting the team to review analytics in standups, not just when something broke. Data only matters if it changes what you build next.

The Real Lesson

You don't need a data engineer to set up useful analytics. You need to be honest about what decisions you're actually making and instrument for those.

Start with three questions you need answered every week. Pick tools with free tiers that you can set up in a day. Make it easy enough that your least technical cofounder can pull numbers without help.

And ship it. Imperfect analytics you use beats perfect analytics you'll build someday.