The metrics that matter by stage, the event taxonomy that scales, the three dashboards every solo founder needs first, the tool ladder from PostHog free to Mixpanel paid, and an eight-week analytics bootstrap plan.
Methodology. This guide synthesizes analytics research from Reforge, OpenView Partners, and the published PostHog / Mixpanel / Heap documentation. Numbers cited are industry benchmarks; results vary by segment.
Most solo founders ship a product, plug in Stripe, watch the dashboard tick up by a few dollars, and call that “analytics.” It is not. Stripe tells you how much money came in. It tells you nothing about which marketing channel produced the customer, what the customer did inside the product before they paid, which feature kept them around, or what they were doing in the week before they cancelled. Without that information the founder is flying blind, optimizing the things that feel productive instead of the things that move the business.
Analytics is the difference between guessing and knowing. It is also the discipline most solo founders skip the longest, often until they have already burned six months on the wrong work. This guide covers the three layers of SaaS analytics, the metrics that matter at each MRR stage, the event taxonomy that does not collapse at fifty events, the dashboards to build first, the tools to pick at each stage, and an eight-week bootstrap plan a one-person team can actually execute.
Ask ten solo founders at $0 to $5K MRR about their analytics setup and roughly nine will give a version of the same three answers. Each of them sounds reasonable in isolation. Each of them is wrong in a way that costs the founder months.
The instinct is that analytics is something you set up once volume justifies it — that with only a hundred signups, the data is too sparse to tell a story. The instinct is backwards. With a hundred signups, each one is precious, and you can actually look at every single user’s journey individually. You can see exactly where person 47 dropped off and ask them why. By the time you have ten thousand signups, individual inspection is impossible and you are fully dependent on aggregate dashboards. The right time to instrument is when the events are still few enough that you can sanity-check each one against a real user’s behavior.
Later never comes. The product accretes features, the codebase grows, and adding analytics across a hundred screens after the fact is significantly more work than adding it across ten. Worse, there is now no historical data — the cohort analyses that depend on month-over-month behavior cannot be run retroactively because the events were never captured. Founders who postpone analytics until they “need” them discover at that moment that they needed them six months earlier.
Stripe shows you revenue. It does not show you which signups activated, which features get used, which marketing channels produced retention versus signup-and-bounce traffic, which onboarding step has the highest drop-off, or what the engagement rhythm of paying customers looks like. Revenue is the output. Analytics is the input. Optimizing the output without instrumenting the inputs is like trying to lose weight by squinting at the scale — you can see whether the number is going up or down, but you cannot tell whether to change diet, exercise, or sleep.
The underlying truth is that without product instrumentation, the founder cannot answer the only question that matters: what is working? They can only answer how much money came in? The first question drives every product, marketing, and pricing decision. The second is the consequence of those decisions, lagging the work by weeks or months.
SaaS analytics is not one thing. It is three distinct disciplines, each with its own tooling, mental model, and audience inside a one-person operation. Treating them as one big blob is why founders give up after two weeks — the surface is too wide to learn at once. Separated, each layer is tractable.
Revenue analytics is the money math. MRR, ARR, churn rate, net revenue retention, customer acquisition cost, lifetime value. The audience is the founder, the investor (if there is one), and the bank account. The data source is the billing system — Stripe, Paddle, Lemon Squeezy. The tools are Stripe’s built-in dashboards, ProfitWell, Churnkey, or a custom MRR tracker. The questions answered are about the business as a financial entity: is it growing, what is the trajectory, what is the runway.
Most solo founders start and end here, which is the mistake. Revenue analytics is necessary but tells you almost nothing about why revenue is what it is.
Product analytics is the behavior layer. Events fired when users do specific things, funnels showing conversion between steps, retention curves showing how long cohorts stay engaged, feature adoption showing what gets used and what does not. The data source is your application code emitting events. The tools are PostHog, Mixpanel, Amplitude, Heap. The questions answered are about user behavior: where do new signups drop off, what is the activation milestone, which features correlate with retention, what does a typical week look like for an engaged customer.
This is the layer that drives product decisions. A founder with strong product analytics can answer “should I build feature X?” with data instead of opinion. A founder without it is guessing.
Acquisition analytics is the funnel above the product. Traffic sources, landing-page conversion rates, cohort behavior segmented by acquisition channel, marketing attribution. The data source is web analytics joined to product analytics joined to billing. The tools are Plausible, Fathom, Google Analytics, plus UTM parameters captured on signup. The questions answered are about the top of the funnel: which channels produce traffic, which traffic converts to signups, which signups convert to paid, and which paid signups stick.
Acquisition analytics is what tells you whether to invest more in SEO or audience-building or paid ads. Without it, marketing dollars get spent by gut feel.
Each layer needs different tools and different mental models, but they all share one anchor: the user. A clean analytics stack joins the same user across all three layers so you can answer cross-layer questions like “customers who came from organic search retain 40% better than customers from paid Twitter ads.” That join is the goal.
The mistake most founders make is tracking dozens of metrics at every stage. The smarter move is to track three to five metrics at each MRR stage and add more only when the prior set becomes routine. Every metric has a cost — the time to compute it, the dashboard space it occupies, the mental load of watching it. Stage-appropriate metrics are the difference between an analytics practice and an analytics ritual.
At pre-product-market-fit scale, the only metrics that matter are signups per week, activation rate (percentage of signups who hit the activation event), and MRR. That is it. Churn is too noisy to measure with thirty paying customers. Cohort analysis needs at least three monthly cohorts to be useful. NRR is meaningless when nobody has had a chance to expand or contract yet. Track what is actually moving and ignore everything else. The whole dashboard should fit on a single screen.
At this stage you have enough customers for churn to start telling a coherent story. Add monthly churn rate, time-to-activation (median minutes from signup to first activation event), and week-by-week retention. The retention curve is the single most important addition — it tells you whether the people who do activate stick around, and that’s the question that decides whether the next $9K of MRR is buildable on the current product or requires a different one.
Past $10K MRR you can run real cohort analysis — comparing the May cohort to the April cohort to the March cohort, looking for whether each successive cohort retains better than the prior. Add net revenue retention (which becomes possible to compute meaningfully now that customers have had time to expand or downgrade), feature adoption by cohort, and customer acquisition cost broken down by channel. The CAC-by-channel breakdown is what tells you which marketing efforts actually pay off versus which are vanity activity.
At $50K MRR and above, you have enough data and enough revenue to justify the full analytics surface. LTV:CAC by cohort. Expansion revenue as a percentage of total. The magic number (net new ARR divided by sales and marketing spend). Quick ratio (new and expansion MRR divided by churned and contracted MRR). At this stage the metrics become a board-meeting language, and the founder spends real time interpreting them rather than just glancing at the dashboard. Most solo founders never need this stage; they exit, plateau, or hire before crossing it. But for those who get there, the metrics surface expands meaningfully.
The single most expensive analytics mistake is also the most invisible. The founder starts firing events ad-hoc as they build features. user_clicked_button_1 in week one. user_clicked_BIG_button in week three after a UX experiment. signup from the marketing page, SignUpComplete from the onboarding flow, completed_signup from the mobile app. Six months later the analytics warehouse contains 200 events with no consistent naming, half of them firing on multiple code paths with different properties. Nothing can be queried reliably. The dashboards lie. The founder gives up on analytics.
The fix is a naming convention picked on day one and applied without exception. The convention most teams converge on is [object]_[verb], past-tense, snake_case. Examples: subscription_started, project_created, invoice_paid, feature_x_used. The object is the noun — what the event is about. The verb is the action — what happened to it.
The convention works because it is consistent and predictable. Six months from now, when you want to know “all the things subscriptions can do,” you search subscription_* and find everything. When you want “all the things that started,” you search *_started. The event names compose. Ad-hoc names do not compose, and that’s why they collapse at fifty events.
The event name is half the story. The other half is properties — the metadata attached to each event that lets you slice and filter later. Five properties belong on every event without exception:
user_id. The single most important property. Without it, events are tied to anonymous sessions and you cannot connect behavior across visits.organization_id (if applicable). For B2B products, the organization or team the user belongs to. Lets you aggregate events at the account level rather than just the user level.plan. The current subscription plan of the user. Lets you slice everything by tier and see how Pro users behave differently from Free.signup_date. The date the user originally signed up. Required for cohort analysis — you cannot group users by signup month without it.source. The acquisition channel (organic, paid_twitter, newsletter, partner_x). Lets you trace any behavior back to the channel that produced it.Adding these properties to every event is mechanical work. Skipping them is the difference between a usable warehouse and a pile of strings that nobody can query. Most analytics tools let you set these as “super properties” that attach automatically to every event, which is the right setup. How to add analytics with PostHog walks through the implementation specifics.
The instinct to instrument everything is the wrong instinct. The instinct to instrument nothing is also wrong. The right move is to instrument five specific events on day one and resist adding a sixth until the first five are answering questions you actually ask.
signup_completed. Fired the moment a user finishes creating an account — verified email, password set, profile minimum filled. This is the top of the product funnel and the denominator for every activation calculation.first_project_created. For an analytics tool: first_dashboard_viewed. For an AI writing tool: first_document_exported. The activation event is the single action that statistically correlates with retention, identified from looking at retained users and asking what they all did in their first session.subscription_started. Fired when a user converts from trial or free to a paid plan. Captures the trial-to-paid conversion event, which is the headline business metric.subscription_cancelled. Fired when a user cancels their subscription. Pairs with a cancellation reason property captured from the exit survey, which is what turns this into actionable churn data.Five events is enough to compute the activation rate, the trial-to-paid conversion, the gross churn rate, and the engagement rhythm. Five events is also few enough that the founder can keep the entire event schema in their head. Add the sixth event only when one of the first five has produced an actionable insight and you need a follow-up question answered.
With the five events instrumented, three dashboards answer roughly 80% of the analytics questions a solo founder asks in the first year. Build these before any others.
A simple funnel chart with three steps: signup_completed → activation event → subscription_started. The chart shows what percentage of signups reach activation, and what percentage of activated users convert to paid. The two conversion rates between the steps are the headline numbers. A healthy SaaS sees 30–60% of signups activate and 5–25% of activated users convert to paid, with wide variation by product and segment.
The dashboard’s job is to surface the bigger drop-off. If activation is 20% but trial-to-paid is 40%, the work is in onboarding — users who get it convert fine. If activation is 70% but trial-to-paid is 5%, the work is in pricing, positioning, or value delivery — users get the product but don’t see it as worth paying for. Two very different problems with two very different fixes; the funnel tells you which.
A retention curve plots, for a given signup cohort, the percentage of users still active in week 1, week 2, week 4, week 8, week 12 after signup. The shape of the curve tells you almost everything about product-market fit. A curve that drops steeply and approaches zero says users tried it once and never came back. A curve that flattens at 30% and stays there says you have a real product with real product-market fit — even though most users left, a stable cohort kept using it. The latter is the shape you want.
The complete guide to SaaS retention covers the curve in depth. For analytics-implementation purposes, build it once for the all-time cohort and again segmented by signup month so you can see whether retention is improving across cohorts.
A monthly bar chart decomposing MRR change into its four components: new MRR, expansion MRR, churn MRR (negative), contraction MRR (negative). The sum is net new MRR for the month. The chart tells you not just whether MRR is growing, but why it is growing. A founder seeing $2K in net new MRR can ask: was that $2K of new customers (acquisition working), $2K of expansion (existing customers upgrading, NRR strong), $4K of new and expansion offsetting $2K of churn (acquisition working but bucket leaking), or some other shape? The diagnosis is in the components.
Most billing platforms have a version of this built in, but it is worth building a custom version that splits by plan, acquisition channel, and customer cohort. The cohort-level view is what tells you whether your last marketing experiment produced customers who stick.
The analytics tooling market is crowded and expensive. Founders routinely overpay at low MRR because tool vendors target enterprise budgets and the pricing pages assume a team with money. The honest stack at each stage:
PostHog’s free tier (1 million events per month at the time of writing) is more than enough for any pre-PMF SaaS. It covers product analytics, funnels, retention, session replay, and feature flags in one tool. Stripe’s built-in dashboard handles the revenue side. Total monthly cost: $0. There is no analytics expense worth incurring at this stage, and any tool that asks for a credit card before you have one is the wrong tool.
Once acquisition becomes a discipline you actually invest in, a lightweight web analytics tool joins the stack. Plausible and Fathom both cost $9–$19/month, are GDPR-friendly out of the box, and answer the questions Google Analytics asks you to fight through twenty screens to answer. The Plausible vs PostHog vs Fathom comparison covers when each makes sense. PostHog stays in the stack for product analytics.
At $10K MRR and above, the analytics questions get more sophisticated. Custom cohorts. Multi-step funnels with filters. Predictive churn models. PostHog Pro covers most of this if you have already invested in PostHog; Mixpanel is the comparable alternative with stronger cohort-analysis UX. Add ProfitWell or Churnkey for revenue analytics — both have free tiers up to certain MRR thresholds, and the dunning and retention features pay for themselves.
Amplitude, Heap, and Mixpanel at their enterprise tiers are excellent. They are also designed for teams of ten with budgets to match. A solo founder paying $300–$1000/month for an analytics tool when PostHog free covers 90% of the use case is paying for a brand badge, not a capability gap. The right time to upgrade to a paid enterprise tool is when the PostHog free tier breaks — when the event volume exceeds what the tier allows, or when a specific feature is genuinely missing and bottlenecking decisions. Until then, free works.
The mistakes below are predictable in the sense that almost every solo founder makes at least two of them. They are also avoidable with thirty minutes of upfront thought.
Some founders, having read that analytics matters, fire fifty events on day one. The result is a warehouse full of data nobody looks at because there is too much of it to make sense of. Five events answer most questions; fifty answer none, because no one builds the dashboards.
The opposite mistake. The founder “will add analytics later” and never does. Decisions get made on gut. The retroactive cost of instrumenting is high enough that the analytics work keeps getting deprioritized. The blind founder cannot answer simple questions like “has activation rate improved over the last quarter” because the data was never captured.
The most insidious bug. Events fire correctly, but they are tied to anonymous session IDs because the analytics SDK was never told who the user is. The data exists; it is unjoinable across visits, across devices, across the signup boundary. Every analytics tool has an identify(user_id) call. Calling it the moment a user logs in (or signs up) is mandatory. How to add analytics with PostHog walks through the call sites.
Page views without conversion attribution. Total signups without activation rate. Newsletter subscribers without engagement. Vanity metrics make the founder feel like the business is working without telling them whether it actually is. The fix is to never report a top-of-funnel number without the conversion rate downstream of it. “Signups” without activation rate is meaningless. “Page views” without bounce rate is meaningless. Pair every input metric with the output it produces.
The founder ships a refactor that renames signup_completed to account_created. Three dashboards break silently. The retention curve, which depends on signup_completed as its starting event, now reads from an empty table. The founder does not notice for weeks. The fix is to treat event schemas like database schemas — documented, versioned, and renamed deliberately with a migration plan. If you rename an event, keep firing the old name in parallel for a month while dashboards are updated.
The work above is a lot to take in as a list. The right way to attack it is as a focused eight-week bootstrap, one week at a time, with a measurable output at the end of each week. This assumes a working product with at least a few dozen signups so the data has signal.
Sign up for PostHog free tier. Add the JavaScript snippet to the product. Verify a test event fires. Set up Stripe webhooks to capture customer.subscription.created, customer.subscription.deleted, and invoice.paid into your application database. The output: events flowing from both the product and the billing system.
Write down the five events specific to your product. Pick the activation event by looking at retained users and asking what they did in session one. Pick the primary value event by asking what action you would want a paying customer to do every week. Add the five tracking calls to the code. The output: five events firing reliably, with the five standard properties attached.
In PostHog, build the three-step funnel from signup to activation to subscription. Save it as a dashboard. Look at the conversion rates between the steps. The output: a saved dashboard you can check weekly to see whether activation or trial-to-paid is the bigger gap.
Build the weekly retention curve for the all-time cohort. Look at the shape. Note where the curve flattens (or whether it does). The output: a saved retention dashboard and a written observation about the shape of the curve.
Using Stripe data plus your database, build the four-component MRR breakdown: new, expansion, churn, contraction. This often requires a small SQL query against the application database rather than a pre-built tool. The output: a monthly bar chart you trust enough to use as your headline business metric.
Audit every event-firing code path in the application. Ensure identify(user_id) is called the moment authentication completes. Verify in PostHog that pre-login and post-login events are joining correctly. The output: a unified user timeline that shows the full journey from first landing-page visit through subscription.
Spend a full afternoon reading the three dashboards and the user timelines. Do not act yet. Take notes. The goal is to develop intuition for what normal looks like. Without a baseline, every dashboard movement reads as a five-alarm fire; with a baseline, real signals stand out from noise. The output: a written summary of what looks healthy, what looks broken, and what looks ambiguous.
Pick the largest gap in the activation funnel, the steepest drop in the retention curve, or the most damaging component of the MRR breakdown. Ship one product change targeting that gap. Measure the change against the dashboard the following week. The output: one shipped improvement, attributable to one analytics-driven insight, with a measurement plan attached.
Eight weeks is the bootstrap. The system, not the answers. Analytics work compounds — the same dashboards used over time produce sharper questions and tighter loops between insight and shipped change. The founder who treats analytics as a quarterly review ritual loses the compounding. The founder who treats it as a weekly fifteen-minute glance keeps the loop alive.
SaaS analytics is the single most-skipped solo-founder discipline and the single highest-leverage one. Pick five events, pick a naming convention, identify users on login, build three dashboards (activation funnel, retention curve, MRR breakdown), and ship one product change based on what they show. Start on PostHog free, add Plausible at $1K MRR, and upgrade to paid tools only when the free tier genuinely breaks. The metrics that matter change as MRR scales — stay disciplined about which ones belong on the board at each stage. Without instrumentation you cannot answer “what is working?” You can only answer “how much money did I make?”
The analytics work above pairs with the upstream and downstream guides on this site. How to add analytics with PostHog is the implementation tutorial. The PostHog review covers the trade-offs of the tool itself, and Plausible vs PostHog vs Fathom covers the marketing-analytics layer. For the metrics themselves, see SaaS metrics that matter, what is MRR, what is churn rate, what is cohort analysis, and what is net revenue retention. The complete guide to SaaS retention sits adjacent to this one — retention is the system analytics measures.
The stack, prompts, pricing, and mistakes to avoid — for solo founders building with AI.