The Metrics We Actually Track at Pre-Seed
Growth charts at our stage are mostly noise. The machine isn't.
A startup is a company designed to grow fast. ... The only essential thing is growth. Everything else we associate with startups follows from growth.
That essay won so completely that its conclusion became furniture. Fourteen years later, every pre-seed deck leads with an up-and-to-the-right chart, and in an accelerator you can watch founders rearrange reality weekly to keep the slope alive. We're in one of those accelerators. The pressure is real.
Here's the problem: at pre-seed, most growth charts are noise wearing a trend's clothes. When your user count is small, one enthusiastic Discord mention produces a spectacular week and one holiday produces a terrifying one, and neither says anything about the company. So this post is about what we track instead: the metrics that measure whether the machine works, because a working machine is the thing growth eventually multiplies.
The machine, not the slope
Everything we watch closely shares one property: it's within our control, it moves when we ship, and it would still matter at 100x the volume. Four of them carry most of the weight.
| Metric | The question it answers | The trap it protects us from |
|---|---|---|
| Time-to-first-deploy | How long from signup to a real app live on a URL? | Demos that impress and onboarding that abandons |
| Activation | Did they deploy something real and come back within a week? | Counting curious tourists as users |
| Gross margin per workload type | Does each static site, container, and database earn more than it costs us? | Growth that loses money faster at scale |
| Support minutes per active user | Does the product explain itself? | Hiring support to subsidize confusing design |
Time-to-first-deploy is the one we treat as sacred, because it's the product thesis in number form: if deploying on Light Cloud isn't dramatically faster than assembling the pieces yourself, nothing else we claim matters. We measure it from account creation to first successful deploy, and we watch the median rather than the average, because one person's broken DNS afternoon shouldn't hide everyone else's experience. Watching that number move after each onboarding change teaches us more than any survey has.
Gross margin per workload type is the unglamorous one, and the one that shapes pricing. A static site, a container, and a managed PostgreSQL instance have wildly different unit economics, and averaging them into one blended margin hides exactly the information you need. Scale-to-zero makes this sharper: an idle workload must cost us close to nothing, or our own pricing model quietly eats us. We rebuilt this spreadsheet three times before it stopped lying.
Retention rides along with activation, cohort by cohort rather than as one blended percentage. A weekly cohort of activated users either keeps deploying a month later or it doesn't, and small cohorts are noisy, so we read the shape across several cohorts instead of panicking over one. The question is always the same: did the people who experienced the product's real value come back for more of it?
There's also a list of things we deliberately don't track, and it's longer than the table above. GitHub stars, social impressions, newsletter opens, raw signups: all of them go up when we're loud and none of them move when the product gets better, which makes them measurements of marketing volume wearing a product costume. A dashboard full of numbers you can inflate by tweeting is worse than no dashboard. It teaches you to tweet.
What investors actually asked
The accelerator conversations surprised us, in a good direction. The growth chart got glances. The questions that kept returning were about the machine: what does a workload cost you, what breaks first at ten times the load, why do the users who leave leave, and which number would you look at to know the product got better this month. One conversation spent its whole slot on the margin table.
That pattern makes sense once you see the investor's problem. At pre-seed there's no trend long enough to trust, so the diligence question isn't "is it growing"; it's "will the unit economics survive the growth you're promising". A margin that's negative per workload doesn't improve with volume. It industrializes.
The steelman: growth still rules
Graham's argument deserves its full weight, and it's aged well. Without growth, none of the machine metrics matter; a beautifully instrumented product nobody adopts is a hobby with dashboards. Investors fund slopes, not intercepts, and his benchmark that a good YC-stage growth rate is 5-7% a week has stayed the industry's mental anchor for over a decade. Ignore growth long enough and you optimize a machine no market is asking for.
All true. The refinement is about sequence, and about sample size. That 5-7% is meaningful once there's a base worth compounding; below that base, weekly percentages are dice rolls, and worshipping them teaches a team to chase spikes instead of causes. Machine first, then slope. We look at the growth numbers too; we just refuse to let them make decisions the activation and margin numbers should be making.
The uncomfortable version of this post fits in one question, and we ask it monthly. If a stranger saw only your metrics dashboard, would they be able to tell what your product does well, or only how loudly it's been marketed? Ours mostly passes. Which of your numbers would survive that test?
Related: Light Cloud Joins the Google for Startups Program, an earlier stop on the same road. More about what we're building at light-cloud.com.