How to measure whether SaaS development company is working

Measure a SaaS development engagement on three clocks: delivery health such as lead time, change failure rate and time to restore; product health such as activation, weekly active accounts, crash-free sessions and Core Web Vitals; and commercial health such as net revenue retention and cost to serve per account. Delivery metrics move first, product metrics second, commercial metrics last.

The practical consequence is that you cannot judge month two on a commercial metric and you cannot judge month twelve on a delivery one. This article sets out which SaaS development company metrics belong on each clock, how to instrument them without building a data warehouse first, the numbers that reliably mislead, and the review cadence that turns all of it into decisions.

Why the usual delivery dashboard fails

Most engagements are reported on velocity, story points burned and tickets closed. These measure how busy a team is, not whether the product is getting better, and they are trivially gameable by splitting tickets. A team can have a perfect burndown chart and a product nobody opens twice.

The second failure is measuring only the end state. Monthly recurring revenue is the number the board cares about and the slowest number in the system. By the time it tells you something is wrong, two quarters of engineering have already been spent. You need leading indicators that move inside a sprint.

The third failure is measuring without a threshold. A metric with no agreed target is a chart, not a control. Every metric below should have a number written next to it before the release that changes it ships.

The metrics that matter, and how to instrument them

Core Web Vitals in particular should be read from real user sessions rather than a lab tool. Google publishes the current thresholds and the field measurement guidance for Core Web Vitals, and the gap between a lab score and field data on a real customer's four-year-old Android device is usually the whole story.

How soon should each metric move?

Delivery metrics move within four to six weeks of a competent team taking over, because they are mostly a function of pipeline, test coverage and release process. If lead time has not fallen by week six, the problem is either the codebase or the decision loop on your side, and it is worth finding out which before month three.

Product metrics move in one to two quarters, because they need a shipped change, enough traffic to detect a difference and a cohort old enough to compare. Activation is the fastest of them; retention is the slowest.

Commercial metrics move over a year. Net revenue retention is a lagging indicator of decisions taken three quarters ago. Building the business case around it is covered in the ROI of a SaaS engagement, which is the paper to write before the work starts, not after.

The numbers that mislead

• Velocity and story points. Internal planning units, not outcomes. Comparable only against the same team's history, and easily inflated.
• Total registered users. Counts curiosity. Weekly active accounts counts value.
• Uptime as a single percentage. Ninety-nine point nine per cent uptime measured on a health check endpoint says nothing about whether checkout worked. Measure availability of the user journeys that earn money.
• Lines of code or commits. Rewarded behaviour is more code, which is the opposite of what a maturing product needs.
• Average response time. Averages hide the tail. Use the ninety-fifth and ninety-ninth percentiles, where your unhappiest users live.
• Ticket volume to support. Falls when users give up as readily as when the product improves. Pair it with activation and retention.
• Test count. Two thousand tests that never touch billing or tenant boundaries are decoration.

Gating releases rather than reporting on them

Turn thresholds into a pipeline step

A metric you review monthly protects nobody. The ones that matter belong in the deploy pipeline as pass or fail conditions: test suites covering authentication, billing and tenant isolation must pass; bundle size and key page performance budgets must hold; database migrations must be reversible. A release that breaches a threshold does not ship, and no discussion is required at eleven at night.

Ship behind a flag and measure the cohort

Every significant change goes to a cohort before it goes to everyone, so the metric change is attributable to the release rather than to the season. That practice is set out in feature flags and beta cohorts, and it is what makes activation a usable metric rather than a noisy one.

Define the error budget, then spend it

A service level objective with an error budget turns reliability from an argument into arithmetic: while the budget has room, ship features; when it is exhausted, reliability work takes priority. Google's service level objectives chapter sets out the mechanics, and the same idea makes support commitments meaningful, as covered in SLAs that mean something.

The review cadence

Weekly, look at lead time, change failure rate, activation and the incident log with the engineering lead, and change one thing. Monthly, look at cost to serve per account, Core Web Vitals and crash-free sessions with the product owner, and decide what goes into the next release. Quarterly, look at retention and net revenue retention with whoever owns the budget, and decide whether the roadmap thesis still holds.

The rule that keeps this honest is that each review ends with a decision, not a chart. If three consecutive reviews produce no change, the meeting is reporting rather than managing.

Measuring the relationship, not just the software

Two numbers tell you more about a vendor engagement than any product metric. The first is decision latency: the median hours between your team asking a technical question and getting a usable answer. The second is estimate accuracy: what proportion of committed scope landed in the committed window, measured over the last six releases rather than the last one. A partner whose estimate accuracy sits above eighty per cent is worth more than one who is faster and wrong.

Add a third if the engagement is meant to end: handover readiness. Count the systems your own engineers could operate today without a phone call. If that number is not rising every month, you are buying a dependency rather than a product. Scope, price and date being fixed is what makes the first two numbers measurable at all, which is the argument in fixed price versus time and materials.

When measurement is the wrong focus

Before product-market fit, most of these metrics are noise. With forty accounts, activation rate has a confidence interval wide enough to drive a lorry through, and optimising it is a distraction from talking to customers. Measure delivery health, keep the product instrumented, and make product decisions from conversations until the numbers are large enough to mean something.

Measurement is also wrong as a substitute for judgement about direction. No dashboard will tell you that you are building the wrong product well. That is a strategy question, and it is answered by customer conversations and a scope decision, not by a chart.

And a warning about over-instrumentation: every event you collect is data you must retain, secure, justify under the DPDP Act and eventually delete. Collect the events you will act on. A tracking plan of four hundred events is a compliance liability wearing an analytics costume.

What this looks like on a real engagement

On the dispatch platform and offline-first driver app we built for a last-mile operator, the metric that mattered was not page load time in an office. It was whether a driver on a weak network in a basement car park could complete a delivery update, which made sync success rate and crash-free sessions the numbers the release gate was built around. Crash-free sessions explains why that one predicts store reviews better than anything else.

The general lesson: pick the one metric that represents your product working for the person who uses it under the worst realistic conditions, and make it a gate.

Related reading

Usage metering and billing for SaaS covers the instrumentation that makes cost to serve and revenue metrics possible, SaaS onboarding that converts covers the activation number in detail, and what a care plan should cost covers who watches the dashboards after launch. Care plans start at $1,000 or ₹68,000 a month and rise to $5,250 or ₹3,40,000 for 24x7 cover with a named engineer, with all figures on the pricing page. Build programmes themselves are scoped on the SaaS and cloud-native development page from $31,500 or ₹20,80,000.

Pick five numbers, write a threshold next to each, and put them in the pipeline; everything else on the dashboard is decoration.