You open your analytics dashboard on a Wednesday morning. You have 27 users. The chart shows a faint heartbeat of activity. You stare at "DAU: 3" and feel like you're doing it wrong.
You're not doing it wrong. You're doing analytics at the wrong scale.
Every analytics guide you've read was written for companies with traffic. They talk about funnels, cohort retention, NPS surveys, weekly active user segmentation. That's all fine advice when you have 5,000 users. When you have 27, it's noise dressed up as signal. You need a different set of questions entirely.
Here's what actually matters at this stage, and what you can safely ignore until later.
The three numbers that matter before product-market fit
Product-market fit (PMF) is the point where users tell you the product is useful by showing up on their own, without you prodding them. Before you have it, most of your analytics work is really trying to detect whether you're getting closer or not.
Three numbers tell you that, and only three.
Signups. How many new people created an account this week? Not visits, not clicks, not impressions. Accounts. A person who signed up has raised their hand. They think there's something here for them.
Activations. How many of those signups actually did the core thing your app exists to do? Not "clicked around," not "set up a profile." The one action. In Draftlytic's case, that's generating a project plan. For a budgeting app, it's connecting a bank account. For a writing tool, it's finishing a first draft. Activation is when a user gets the value you promised. If signups are fine but activations are low, your onboarding is the problem, not your marketing.
Return visits in week 2. Did anyone come back? A user who returns in their second week has found something worth returning to. This number, at small scale, is the clearest early signal of whether you have a product that people want to keep using. It's also the number most indie devs never look at because the week-2 cohort is "too small to be meaningful." Six people out of twenty-seven returning in week 2 is not too small. It's telling you something real.
Everything else (session length, page views, time on site, bounce rate, daily active users) is noise until you have enough traffic to detect patterns. Track those three numbers in a spreadsheet if you have to.
Which analytics tool is actually enough right now
The standard advice is to "just use PostHog" or "Plausible is great for indie projects." Both are fine. But before you spend time integrating any tool, answer an honest question: will you look at a dashboard every day, or will you mostly forget it's there?
If you'll mostly forget it's there, your analytics setup doesn't matter yet. The best tool is the one you'll actually check.
With that caveat, here's the honest breakdown:
Plausible (opens in new tab) is excellent for page-level traffic. It tells you where visitors are coming from, which pages they land on, where they drop off. It's privacy-friendly, fast to set up, and cheap. It won't tell you anything about what users do inside your app after they log in. Good enough if your problem is traffic visibility, not product visibility.
PostHog (opens in new tab) does product analytics: custom events, funnels, session recordings, feature flags. It has a generous free tier. The tradeoff is setup time. You need to instrument events yourself, which means writing a few lines of tracking code every time you add a feature. For an app with real user interactions you want to understand, PostHog is worth it.
Umami (opens in new tab) is open-source, self-hostable, privacy-first. Sits between Plausible and PostHog in power. Good if you're on a hosting setup where you'd rather run your own instance. Roughly Plausible-level for product analytics.
console.log and a spreadsheet. Genuinely not a joke. If your app is backend-driven, you already have logs. You can extract activation counts, return rates, and error patterns from logs with a bit of grep or a log viewer. Adding up signups in a Notion table every week is slower than a dashboard, but it forces you to think about what you're measuring instead of passively consuming charts.
For most indie apps pre-PMF with under 100 users: Plausible for traffic plus PostHog for in-app events is the sweet spot. You don't need both Amplitude and Mixpanel and Heap running simultaneously. Pick one and learn it.
The events worth tracking on day one
If you do set up event tracking, these are the ones to instrument before anything else. Everything else can wait.
Signup. Fire when an account is created. Include the source if you have it (did they come from Product Hunt, a referral link, organic search?). Knowing how your best users found you is worth more than knowing how many tabs they had open.
First core action. Whatever activation looks like in your product. Fire this once, the first time a user does the thing. You want to know: what percentage of signups get here? If it's under 30%, something between signup and activation is broken.
Export or share. In many apps, this is the "I got real value" signal. A user who exports a document, shares a link, or invites a teammate has gone far enough into the product that they want to take something out of it. This event is a strong leading indicator of retention.
A churn signal. This is the one most people skip. Build a simple event that fires when a user does something that usually precedes them leaving: cancels a subscription, visits the pricing page without converting, fails the same action three times. You won't have enough data to act on it at 27 users, but having the data when you hit 200 is valuable.
Don't track 40 events. Track four. A bloated event taxonomy is a signal you're avoiding the harder work of talking to users.
Why session recordings beat funnels at low traffic
A funnel shows you aggregate drop-off rates. At 27 users, that's meaningless. You don't have statistical significance. You have noise.
What you do have is 27 specific people whose behaviour you can actually watch.
Session recordings (PostHog does them, so does Microsoft Clarity (opens in new tab) for free) show you a video replay of exactly what a user did in your app: where they clicked, where they hesitated, what they tried twice before giving up. You can watch your 27 users one by one and understand what's confusing or broken in a way no chart can replicate.
This is the thing no analytics-at-scale guide tells you: with a small user base, qualitative beats quantitative. You're not doing statistics. You're doing user research. A funnel that says "60% of users drop off at step 3" gives you a problem. Watching a session recording of step 3 gives you the reason.
At low traffic, session recordings and user conversations do more work than funnels. Watch the recordings. Email the users who activated. Ask what brought them back. You'll learn more in one Friday afternoon of recordings than a month of chart-watching.
That connects to something the first 100 users guide for indie apps makes the same point about: ten real conversations with users outperform any metric dashboard until you have scale.
When to start building real funnels (roughly 500 weekly users)
At some point, individual behaviour becomes too noisy to learn from and aggregate patterns start to matter. That tipping point, for most analytics indie SaaS use cases, is around 500 weekly active users.
At that scale, a funnel with statistical significance is possible. A/B tests become meaningful (with wide enough confidence intervals). Cohort retention curves start to look like curves rather than random lines. You can segment by signup source or feature usage and see actual differences between groups.
Before 500 weekly users, funnels are directional at best and misleading at worst. A 40% drop-off at a step could be a real problem or just the one day your app was slow. With 500 users per week, you can wait a week to get enough data to know.
The transition also marks when tooling decisions matter more. If you've been using Plausible for traffic and a spreadsheet for activation counts, around 500 weekly active users is when you'll want proper event tracking, funnel views, and retention cohorts in PostHog or a similar product analytics tool.
Until then, check your three numbers weekly (signups, activations, week-2 returns), watch session recordings for anything confusing, instrument four events, and spend the time you saved not building dashboards actually talking to users.
If you're pre-launch and trying to figure out what to set up before you open the doors, the vibe-coded app launch checklist covers analytics setup alongside the other practical pre-launch steps.
The honest summary
DAU at 27 users is a vanity metric. It goes up when you post on X, down when you don't, and tells you nothing about whether anyone finds your app worth coming back to on their own.
The number that tells you something is week-2 returns. The behaviour that tells you something is a session recording of someone struggling. The conversation that tells you something is an email reply from a user who came back without being prompted.
You don't need analytics. You need feedback. Analytics becomes feedback at scale. At 27 users, feedback is feedback.
Start with Draftlytic when you're still figuring out what to build. Decide what to measure once you've built it, and measure the right things at the right scale. Most indie apps don't drown in bad data. They drown in the right data, read at the wrong resolution.