Getting Started

When startups actually need analytics (and what happens when you skip it)

Essential metrics for startup analytics: user growth, activation, retention, and cohort analysis to validate product-market fit and guide development.

📅
📖5 min read

When startups actually need analytics (and what happens when you skip it)

Quick answers

When does a startup actually need analytics? When any of these happen: an investor asks a question nobody can answer, a feature gets built twice because nobody checked if it existed, or decisions are being made based on the loudest opinion in the room rather than data. At 5–15 people, these problems are already compounding.

What's the cost of skipping analytics at an early-stage startup? Decisions get made on gut feel instead of data. The same questions get re-answered manually every week. Features get shipped without validation. Onboarding becomes a black box. None of these is fatal alone — together, they compound into a product that's busy but not improving.

What does "good enough" analytics look like for a startup with 10 people? One dashboard everyone looks at (signups, activation, WAU, churn), a way for non-engineers to answer ad hoc questions without pinging the dev team, and event tracking on signup, activation, and first return. That's it. Metabase connected to your production database gets you there in an afternoon.

How do I set up Metabase at a startup? Install Metabase with one Docker command or try Metabase Cloud free for 14 days. Connect your database, spend an afternoon building five charts, and you have a working analytics layer with no data warehouse required.

How do I let non-technical teammates answer data questions without asking engineering? Use Metabase's query builder — it lets anyone filter, group, and summarize data by clicking through a UI, no SQL required. Set up a shared dashboard for recurring questions and alerts to help teams stay on top of important changes. Most questions stop reaching engineering within a week.

What events should a startup track in their database? At minimum: user created (with acquisition source), core activation event, first return visit or session. That's enough to answer whether you're acquiring the right users, whether they're getting value, and whether they're coming back. Add more events when a specific question can't be answered with what you have.

---

Early-stage teams skip analytics for a good reason: they're moving fast, talking to users directly, and don't have time to instrument everything. That trade-off is defensible.

At some point it stops being defensible. The question is whether you know when that point is.

The moment it becomes a problem

It's usually one of these:

  • An investor asks a question in a meeting and nobody has the number
  • Two engineers spend a sprint building something that users asked for six months ago but already stopped caring about
  • Someone in sales promises a feature based on a hunch, and you build it, and it goes unused
  • The CEO makes a product decision based on a conversation with one customer
  • None of these are catastrophes. Enough of them compound into a product that's busy but not improving.

    What "no analytics" looks like at 5–15 people

    Decision-making by whoever talks loudest. Without data, opinions win. The people with the most confidence or the most access to customer conversations set the direction.

    Constant re-answering of the same questions. "How many users did X last month?" gets answered fresh every time it's asked — by whoever has database access and is willing to write the query.

    No way to validate a shipped feature. You deploy, you move on. You find out if it worked when someone mentions it in a call three months later.

    Onboarding is a black box. You know how many people signed up. You have no idea how many reached the point where the product made sense.

    What "good enough" looks like at this stage

    Good enough is:

    1. One dashboard everyone looks at.

    Signups, activation rate, weekly active users, churn. Not 40 metrics — four or five that reflect the health of the business. In Metabase, you build this once and share a link. Everyone on the team can open it without touching a database. The dashboards support filters, drill-through, and interactivity — so it's not just a static screenshot that goes stale.

    2. A way to answer ad hoc questions without writing code.

    Someone should be able to ask "how many users on the Pro plan activated in the last 14 days?" and get an answer in under five minutes without pinging an engineer. Metabase's query builder handles this — no SQL required. For the ones that need SQL, the SQL editor has autocomplete and lets you save queries for later.

    3. Event tracking on the things that matter.

    Signup, activation event, first return visit. You need a meaningful events table in your production database. Metabase queries it directly — no pipeline, no warehouse, connects in minutes.

    Setting up Metabase at a startup

    Metabase is open source and free to self-host. You can run it as a Docker container, a JAR, or on Metabase Cloud with a free 14-day trial. Connect it to your production database, spend 5 minutes building five charts, and you have a working analytics layer.

    For teams that want to stay on top of things without remembering to check a dashboard, alerts fire when a metric crosses a threshold — useful for things like "tell me if signups drop below X this week."

    The compounding cost of skipping this

    Analytics debt is like technical debt — it doesn't hurt immediately, and it compounds quietly. Every quarter you build without a feedback loop is a quarter where you might be building the wrong things.

    The teams that skip analytics at 10 people and fix it at 40 spend the first few months at 40 trying to figure out what was actually happening the whole time. That's an expensive retroactive audit.

    You don't need to be sophisticated about this at the early stage. You need to not be blind.