Your first weekly metrics review: the one number that tells you it is working

You have one acquisition channel running. You instrumented the path last week, so signups now carry a source. Money is coming in, slowly. And every morning you open Stripe, glance at the MRR number, feel something (usually mild dread), and close the tab. That is not a metrics review. That is anxiety with extra steps.

The job this week is to replace that random glance with one fifteen-minute habit: a weekly review built on a tiny set of numbers you can actually act on. Not a dashboard with forty tiles. Not a BI tool. One screen, four numbers, a fifteen-minute slot in your calendar, and a decision at the end of it.

Here is the uncomfortable truth about a three-to-thirty-customer SaaS: most of the numbers people tell you to track are noise at your scale. Bounce rate, session duration, NPS, churn percentage to two decimal places. With twelve paying customers, a churn rate is one person leaving versus zero, which swings from 0% to 8% on a single email. The signal you need is smaller, blunter, and far more honest.

The one number that matters (and it is not MRR)

If you only get to look at one number each week, do not make it MRR. MRR is a lagging, distorted figure at your stage. It moves when an annual plan lands, it gets muddied by the founders you grandfathered when you raised prices, and it tells you nothing about why it moved. By the time MRR drops, the decision that caused it was made six weeks ago.

The one number to lead with is net new paying customers this week. Not revenue, customers. Count them as a plain integer: how many people started paying you this week, minus how many stopped. Plus three is a good week. Zero is a flat week. Minus one means a customer left and you need to know who and why before Friday.

Why a count and not a currency value? Because at small numbers, a count is impossible to lie to yourself about. "MRR is up 4%" can hide the fact that one annual upgrade masked two cancellations. "Net new paying customers: minus one" cannot hide anything. It forces the question that matters: who left, and was it preventable?

Around that headline number, you want three supporting numbers, and no more:

• Signups this week (top of funnel, by source)
• Activation rate (of this week's signups, how many hit your one activation event)
• Cancellations this week (with names, not just a count)

That is the whole dashboard. Net new paying customers, signups by source, activation rate, cancellations by name. Four numbers. If you find yourself wanting a fifth, ask what decision it would change. If the answer is "none, but it would be nice to see", leave it out. Every tile you add is a tile you have to glance at and discount every single week.

Why a count beats a rate at twelve customers

This is worth labouring because it is where most early founders go wrong. They copy the metrics that growth-stage SaaS companies track, because those are the metrics every blog post and every analytics tool puts front and centre. Cohort retention curves, monthly churn rate, LTV to CAC ratio.

Those metrics are real, and they will matter to you, but they need volume to mean anything. LTV needs enough customers to have churned at predictable points so you can estimate an average lifetime. With twelve customers and three months of history, your "average customer lifetime" is a guess dressed up as a number. Tracking it to two decimal places gives you false precision, and false precision is worse than no number at all, because you will make decisions on it.

Counts do not have this problem. "Three people signed up from the UK indie-hacker forum, one activated, none have paid yet" is a complete, true, actionable sentence at any scale. You do not need a hundred data points to read it. You need one week.

So the rule for the next few months: track counts, not rates, and track names, not aggregates, wherever a name is possible. When you cross roughly a hundred paying customers, rates start to stabilise and you graduate to cohorts and curves. Until then, integers and names.

Build the dashboard in one Claude Code session

You do not need a third-party analytics product for this. Your data already lives in Supabase: a subscriptions or customers table from your Stripe integration, a signups or users table with the source column you added last week, and an activation_events table if you instrumented your activation event. Everything you need is one SQL query away.

Resist the urge to wire up a charting library and a polished admin page on day one. The first version of your weekly review is a single SQL query you run by hand, or a one-page internal route that prints four numbers as plain text. Loud and ugly beats pretty and unbuilt.

Open Claude Code in your project and give it a tight brief. Something like:

Write a SQL query against my Supabase Postgres that returns, for the last seven days: (1) count of new paying subscriptions, (2) count of cancelled subscriptions, (3) net of those two, (4) count of new signups grouped by the source column, and (5) of this week's signups, how many have a matching row in activation_events. Use the actual table and column names in my schema, which you can read from the migration files. Return it as one query I can paste into the Supabase SQL editor.

Two things make this work. First, point Claude Code at your real schema. Tell it to read your migration files or your schema.sql so it uses your actual column names rather than inventing plausible ones. A query that references a column you do not have is worse than no query. Second, ask for the SQL first, the page second. Get the numbers right in the Supabase SQL editor before you spend a single token building a route to display them.

Once the query returns sensible numbers, you can ask Claude Code for a thin internal page: a single authenticated route, server-rendered in your Next.js app, that runs the query and prints the four numbers. Gate it behind your own login so it is not public. Keep it deliberately plain. The goal is a page you can open in fifteen seconds on a Monday, not a product feature.

A note on getting the query genuinely right: ask Claude Code to also write you two or three sanity-check queries you can eyeball against Stripe's own dashboard for the same week. If your "net new paying customers" number does not match what Stripe shows you for the same seven days, the query is wrong, and you want to find that out now, not after you have made three weekly decisions on a bad number. Money-path numbers deserve a reconciliation step.

The fifteen-minute review ritual

A dashboard nobody looks at is a database query with extra hosting costs. The dashboard is only half the job. The other half is the ritual: a fixed fifteen-minute slot, same time every week, where you look at the four numbers and make exactly one decision.

Put it in your calendar as a recurring block. Monday morning is the obvious slot, because it sets the week's focus. The agenda is fixed and short:

1. Read net new paying customers. Positive, flat, or negative? Say the number out loud. Do not soften it.
2. If anyone cancelled, open their name. Look at how long they were a customer and whether they ever activated. If you can, send them one honest question: "what would have made you stay?" This is the highest-value five minutes in the whole review.
3. Read signups by source. Is your one channel still producing? A channel that quietly went to zero is the most common silent failure at this stage, and the only way you catch it is by looking weekly.
4. Read activation rate. Of the people who signed up, did they reach first value? A healthy top of funnel with a broken activation rate means you are filling a bucket with a hole in it.
5. Make one decision. Not five. One. "This week I will talk to the customer who churned." Or "signups from the forum dropped to zero, so I will post there again on Wednesday." Or "activation is fine, customers are fine, channel is producing, so I change nothing and keep shipping the feature I am mid-way through."

That last option is the one founders skip, and it is often the right call. A good weekly review frequently ends in "change nothing". The discipline is not to invent work because you feel you should be doing something. The discipline is to look honestly, decide deliberately, and then close the laptop and get back to building.

Write the decision down in one line somewhere durable. A pinned note, a row in a Supabase table, a line in a text file. Next week, the first thing you do is check whether last week's decision happened and what it changed. That loop, decide then check, is what turns a dashboard into a habit and a habit into a feedback system.

What to deliberately ignore

Half of building a useful review is refusing to track the tempting things. At three to thirty customers, ignore:

• Vanity traffic. Page views, unique visitors, time on site. They feel like progress and predict nothing about revenue at your scale. The signups-by-source number already captures the only traffic that matters: the traffic that converted.
• Churn rate as a percentage. Track cancellations as a count with names. A percentage with a denominator of twelve is theatre.
• NPS and satisfaction scores. You have few enough customers that you can just talk to them. A survey score is a poor substitute for a conversation you are perfectly able to have.
• Daily checking. Looking every day does not give you more signal, it gives you more noise and more anxiety. The data does not change meaningfully day to day at this scale. Weekly is the right cadence. Resist the morning Stripe glance, it teaches you nothing and costs you calm.
• Forecasting and projections. You do not have the data to forecast and you do not need to. Forecasting is a growth-stage activity. Your job now is to read this week honestly and decide one thing.

The through-line: every number you track should change a decision. If you cannot name the decision a metric would change, that metric is decoration, and decoration is just another thing to scan past on a Monday morning.

When to graduate to real analytics

This minimalist review is right for now, not forever. You will know it is time to add proper analytics when the counts stop being legible. Concretely: when you cross roughly a hundred paying customers, when "net new paying customers" stops being a number you can hold in your head and reason about case by case, or when you genuinely need to compare cohorts over time to answer a real question you keep hitting.

At that point, rates start to mean something, retention curves stabilise, and a proper analytics layer earns its keep. You graduate from integers and names to cohorts and curves, and you let Claude Code build you the charting page you sensibly avoided building today. But that is a problem you want to have, and you will not have it until the simple weekly review has done its job of keeping you honest, week after week, until the numbers got too big to fit on one screen.

For now: four numbers, fifteen minutes, one decision. Build it this week.