Indie Hacker Analytics Setup: From Zero to First Insight in 30 Minutes

Most indie hackers either skip analytics entirely or spend a weekend wiring up Amplitude, PostHog, and Segment, then never open the dashboard again. Both failure modes lead to the same place: shipping features by gut feel, with no idea which ones moved the needle.

This post is a no-fluff indie hacker analytics setup. The exact stack, the 5 events to instrument on day one, and how to read your dashboard in under a minute. The whole thing should take 30 minutes, not a weekend.

The 30-minute rule

If you cannot finish your analytics setup in one sitting, you will never finish it. Indie hackers ship in nights and weekends. Any tool that needs more than 30 minutes from “create account” to “first insight on the dashboard” loses to the tool that needs 5.

That single rule rules out about 80% of the analytics market. What is left:

• A tool with one snippet and one event call
• A free tier that does not run out at 1,000 events
• A dashboard that loads in under a second

That is your shortlist. For a deeper comparison see the Amplitude alternatives breakdown.

The stack, in three lines

For a solo indie hacker shipping a SaaS, side project, or directory:

1. Page views and traffic sources: Plausible, Fathom, or Simple Analytics. Cookieless, fast, free tier covers most projects.
2. Product events (signups, activation, retention): Eventraze or PostHog. One snippet, one event API.
3. Errors: Sentry free tier. Catches the bugs your users will not report.

Skip Segment. Skip a CDP. Skip a data warehouse. You do not have data engineering problems yet. You have a product problem.

The 5 events to instrument on day one

You do not need 7. You do not need 12. As an indie hacker, you need 5. Anything else is procrastination.

1. signup_completed

The account was created and confirmed. Not “signup form opened.” Not “verification email sent.” The user has a working account.

Properties: plan (free/paid), source (organic, twitter, hacker_news, referral).

2. core_action_completed

The single action that defines your product. For a meeting tool, a meeting got booked. For a budget app, a transaction was logged. For a directory, a listing was published.

Pick one event. Argue with yourself if you must, then pick one. This is the event that tells you the product works.

3. core_action_repeated

The same user did the core action a second time. Not the same day, just ever. This is your real retention signal at small scale, much more useful than DAU/MAU when you have 40 users total.

4. paywall_hit

A free user bumped into a paid feature. This event tells you whether your free tier is too generous (paywall never fires) or too strict (paywall fires immediately, and they leave).

5. upgrade_completed

A user paid you. This is the only event your accountant cares about, and the only one you will compare against everything else.

That is the whole list. If you can answer “how many people signed up, did the thing twice, hit a paywall, and paid” you have a product analytics setup that is better than 90% of indie projects.

For a fuller version of this thinking once you cross 500 users, see the activation metrics deep dive.

How to read your dashboard in 60 seconds

A dashboard you do not open is worse than no dashboard. Build the habit early.

Every Monday morning, three numbers:

1. New signup_completed last week vs. the week before
2. core_action_repeated divided by signup_completed last week (your activation rate)
3. New upgrade_completed last week

Three numbers, one minute, written in a Notion page or a tweet to yourself. If activation rate dropped, dig in. If signups dropped, look at traffic sources. If upgrades dropped, look at paywall hits. That is the entire ritual.

You do not need cohort tables, retention curves, or funnel breakdowns in week one. Those are the tools you reach for after the three numbers stop telling a clear story, usually around 1,000 weekly active users.

What to skip until you actually need it

The list of features that sound critical and are not, when you are still indie:

• A/B testing. With 40 weekly signups, you cannot detect a 50% lift in a reasonable time. Ship the change. Compare the next two weeks.
• Session recordings. Useful eventually. Distracting on day one. You will spend two hours watching one user instead of fixing the obvious bug they hit.
• Custom dashboards. The default dashboard is enough. Customizing it is a procrastination move.
• Server-side event collection. Client-side is fine until you have at least one real customer asking for SOC 2.
• A data warehouse. You do not have data, you have events. Different problem.

If you find yourself reading docs about any of those during your first 30 minutes of setup, close the tab.

The actual setup, end to end

What 30 minutes looks like in practice:

1. Sign up to Eventraze or PostHog (2 minutes)
2. Drop the snippet in your <head> (3 minutes)
3. Add the 5 event calls in the right places in your code (15 minutes)
4. Push to production, fire each event manually with your own account (5 minutes)
5. Open the dashboard, confirm all 5 events show up (5 minutes)

You are done. You now have product analytics. The next 11 months are about reading the dashboard every Monday and shipping based on what it says, not about adding more events.

Most indie projects die not from lack of data, but from lack of the discipline to look at the data they already have. The 30-minute setup is about removing every excuse not to.