Analytics for indie hackers and side project builders

Quick answers

What analytics does an indie hacker actually need? Three questions cover most of it: where are people coming from, are they doing the core thing the product is for, and are they coming back? Everything else is optional until you've answered those three consistently.

What's the minimum analytics setup for a side project? Something lightweight on the frontend for traffic, and Metabase connected to your production database for product behavior. If you have a users table and an events table, you already have the data — Metabase is how you query it without writing a new script every time.

How do I find users who signed up but never activated? Query your database for users created in the last 30 days with no matching activation event. Save that query in Metabase's SQL editor and it becomes a re-engagement list you can run any time — no manual SQL every time you need it.

What should be on a first dashboard for a side project? Four charts: signups over time, activation rate, retention by week, and users with no activity in 14+ days. Build them in Metabase, share the link, set up a weekly email subscription. That's your full analytics layer for an early-stage project.

How do I know if a feature I shipped actually changed user behavior? Track the metric the feature was supposed to move before you ship — activation rate, return visits, a specific event count. After shipping, compare the week-over-week trend in Metabase. If the line moved, it worked. If it didn't, you know before you've spent another sprint doubling down.

Is Metabase free for indie hackers? The open source edition is free to self-host with no time limit. Run it with one Docker command and connect your database. Metabase Cloud has a free 14-day trial if you'd rather not manage the infrastructure.

---

You built something, shipped it, got some signups, and now you're guessing.

Are people actually using it? Who converted and who bounced on day one? Which tweet drove the spike? Is that user who signed up last week still around?

Guessing is fine when you're pre-launch. Once people are using your thing, guessing is just leaving money on the table.

What you actually need to know

Most side project analytics conversations jump straight to tools. Start with the questions instead.

The three questions that matter most for an early-stage project:

• Where are people coming from? — So you know where to spend your time (and money)

Everything else is nice to have.

The minimum setup

You don't need a full data stack. Here's what actually gives you signal:

For traffic and acquisition: Something lightweight on the frontend. You want to know which pages and sources drive signups.

For product behavior: Your production database. If you're storing users, actions, and events — even a simple events table — you already have the data. You just need a way to query it without writing a new script every time.

For answering questions: Metabase connected to your database. Free to self-host, up in minutes. The questions you'll want to answer — "how many users completed onboarding this week?", "which users haven't logged in for 30 days?" — live in your database, not in your frontend analytics tool.

If you don't want to write SQL, Metabase's query builder lets you answer most of those questions by clicking through a form. If you do want SQL, the SQL editor is right there with autocomplete and saved snippets.

What to track in your database

At minimum, log:

That's enough to answer the questions that actually matter at this stage. Save your key queries in Metabase and they're there the next time you need them — no copy-pasting from your notes.

Building your first dashboard

In Metabase, you build a dashboard by saving individual questions and pinning them together. Takes about an afternoon the first time.

The four charts worth building first:

Share the dashboard link with a co-founder, an advisor, or a beta user. Set up a weekly email subscription so you're looking at it even when you forget to.

The mistake most builders make

Tracking everything. It feels thorough; it's actually noise.

If your database has 50 different event types and you check none of them regularly, you don't have analytics — you have a log. Pick the three metrics that would tell you whether the project is working or dying, and look at those first.

When analytics starts paying off

The moment you ship something and can tell within a week whether it changed user behavior, you've closed the loop. That feedback is what separates builders who improve their product from builders who just keep adding features.