Your first month running a SaaS: which numbers help you decide?

For the first month of a SaaS, start with four questions: did a customer reach a useful result, did they come back for another one, did they pay, and how much help did you provide? Keep the customer count beside every percentage. Those answers can guide next week's work long before you have a meaningful annual growth chart.

Buying an existing SaaS product gives you software to operate and adapt. Your first month is where you learn how that product fits a particular audience, offer and onboarding process. The useful measurement is the customer's work getting done.

Below is a small, fictional scheduling business. Its numbers are calculated from an invented set of workspace records, not SaaSCode customer results or an industry benchmark. The example shows how the same month can contain encouraging repeat use and a specific onboarding problem.

Define the customer and the first useful result

For this scheduling service, one workspace represents one customer business. Three employees signing in to the same workspace still represent one customer. Counting people would answer a different question about participation inside that business.

This distinction also exists in analytics software. PostHog's group analytics documentation describes aggregating events by companies, organizations or other entities instead of individual people. You can use the same account-level logic in a small spreadsheet before choosing an analytics system.

Our proposed activation event is the first confirmed appointment with a real client saved in the workspace. Exclude demonstration bookings and your team's test accounts. Creating an account or opening a calendar is a step toward that result.

Decide the measurement rules before reviewing the results:

• Count activation within the first seven calendar days: signup day is day 0, followed by days 1–6.
• Count repeat use when another real appointment is confirmed on days 7–13 after the first result. The first-result day is day 0 for this second clock.
• Record whether someone needed hands-on help to reach that first result.
• Review successful payments and support work through the end of launch day 30.

These are rules for this example. A monthly reporting product may need a much longer return window. Use the cadence of the customer's actual job, and keep that definition stable while comparing cohorts.

Follow one cohort through the month

A cohort is a group you agree to follow together. Here, it contains the ten workspaces that signed up on launch days 1–7. Two more workspaces join near the end of the month; we track them separately so that they get the same opportunity to act.

By the end of day 30, this is what happened to the first ten:

Original diagram of the fictional cohort. Payment and repeat use are separate measures; their denominators are shown explicitly.

The repeat-use denominator is six because that question follows timely activated workspaces. A signup-to-repeat measure would be four out of ten, or 40%. Both can be useful, but they describe different things. Calling either simply “retention” would hide the distinction.

One more workspace reaches its first result late, on day 14 after signing up on day 5. Record that recovery. It does not retroactively turn a missed seven-day activation window into a success.

Check who has had enough time

All six timely activations in the early cohort have completed their repeat observation window by day 30. The later signups have not had equivalent exposure.

Workspace K signs up on day 25 and activates on day 27. Its repeat window is launch days 34–40, entirely after the reporting cutoff. Workspace L signs up on day 28; even its initial seven-day activation window ends after day 30. Neither belongs in the early cohort's failure count.

The same rule produces different calendar windows. “Not yet observable” is a separate state from “did not return.”

PostHog's retention documentation separates a starting event from a return event and distinguishes returns within a specific period from returns on or after it. When using a dashboard, check its settings against your written definition. A chart with a familiar label can still use a different clock.

Turn the weak point into next week's work

The fictional records make the onboarding problem more specific. Four workspaces reach the first result without hands-on assistance; all four return in the chosen window and make a first payment. Two other workspaces activate with help, but neither returns in that window or pays by day 30.

That is a useful investigation lead. It does not show that help caused weaker outcomes. The assisted customers might have had more complicated schedules, less urgent demand or a different understanding of the offer.

Review those two journeys. For example, did they need help translating their opening hours into appointment availability? Could they make the next change themselves? Did the setup call end with a booking they would have created anyway?

If the same configuration step blocked both, a focused next action would be to improve that step and watch the next comparable customers use it. Write down what changed and whether assistance was still required. Avoid changing the audience, price and onboarding flow at once if you want a useful comparison.

If you are still deciding who should try the product, start with finding the first paying customers for a niche SaaS. This monthly review becomes more informative when the offer addresses a recognizable customer job.

Keep paid demand separate from recurring revenue

In the example, four workspaces have completed a successful first payment by day 30. That is evidence of four paid starts under this offer. Record the amount, currency, refunds and what the payment covered in your own business. A setup payment and a software subscription answer different questions.

Monthly recurring revenue, or MRR, is a separate measure. Stripe's explanation of MRR describes normalizing subscription amounts to a month; an annual subscription does not count as its entire annual value each month. Its calculation can also include active and past-due subscriptions, so MRR is not a receipt of money collected.

For the first month, keep a short payment record alongside product use: who paid, when, for what, and whether the money was refunded. Reconcile it with the payment provider rather than inferring payment from an account label.

Our fictional dataset supplies no payment amounts or renewal history. It therefore supports neither an MRR figure nor a claim about long-term customer value. A customer whose renewal has not come due cannot demonstrate a successful renewal yet. If a renewal later fails, treat payment recovery and customer access as an operating workflow with its own decisions.

Measure the work behind each customer

Nine support requests can hide very different workloads. In this cohort, the two assisted workspaces account for 105 of the 165 recorded support minutes. The other eight account for 60 minutes between them.

The average across all ten is 16.5 minutes per workspace. That average conceals where most of the work happened. Keep a simple reason beside the time: availability setup, importing information, permissions, a defect, or a question about the offer.

Support time in the example includes the hands-on activation help. Do not add it again as a separate cost.

This tells the operator where to investigate, not what to automate automatically. A repeated setup task might deserve clearer instructions, a product improvement or a separately scoped service. An unusual request from one customer may simply need a clear boundary.

Support minutes also do not represent your full operating cost. Add hosting, providers, maintenance and other real expenses separately. For an AI feature, record its attributable provider usage as well; a customer can be active while expensive to serve. Use actual charges and your own labor assumptions before deciding whether a price is sustainable.

Keep the record small enough to maintain

You can begin with one row per workspace: signup date, first useful result, assisted or independent, qualifying return, successful payment, support minutes and a short next-action note. Keep a stable workspace ID so that usage, payments and help refer to the same customer.

Verify a few records against the underlying work. A duplicate event should not become a second customer; a page reload should not become a confirmed appointment. When tracking is incomplete, label the result unknown and repair the record before making a product decision from it.

At the weekly review, write one sentence that connects evidence to action. For this fictional cohort:

Four workspaces repeated the core job and paid; the two assisted activations did neither within our windows. Next week we will investigate their availability setup and test one improvement with the next comparable customers.

This remains a hypothesis. With ten workspaces, one customer changes a signup-based percentage by ten points. Keep the counts and individual explanations visible; a move from 60% to 70% is not by itself proof that your change worked.

What should wait until you have more history?

Record cancellations as they happen, but avoid presenting an immature cohort as a stable churn rate. Keep acquisition spending visible, but be careful about a customer acquisition cost based on a handful of sales and uncounted founder time. Avoid projecting lifetime value from a month that contains no observed renewals.

Your first month can still produce a concrete decision: improve a specific onboarding step, clarify the offer, change a support boundary, or continue serving the same audience while the next cohort matures.

Before launching a second SaaS, use that record to judge whether the first business is becoming repeatable and whether you have capacity for another. A working product is the starting point. The monthly review helps you choose the operating work that makes it useful to your customers.