Unit economics at your scale

The ledger is nearly full now. Every project has a state and a verdict with a date on it, one has a measured maintenance number, and the one you are pursuing has a price you can defend, a payment path, a free/paid line and a distribution plan sorted into work that compounds and work that does not. What it does not have is a single dollar of revenue, because nothing in this course has asked you to launch or charge yet.

That is the awkward position this module opens in. You are about to be handed the vocabulary the whole industry uses to decide whether a product is worth keeping — CAC, LTV, the ratio between them — and almost every word of it was built to describe a company that has customers, spends money to get more of them, and has more money waiting to spend once the numbers come out well. You have none of those three. So the job here is not to learn the metrics and apply them. It is to learn them precisely enough to see which parts survive the trip down to your scale, and to build the one number that replaces the rest.

CAC and LTV, defined properly

Both terms have short entries in the glossary, and short is not enough here, because the argument in this lesson turns on what the standard definitions quietly assume.

CAC — customer acquisition cost — is published by the Corporate Finance Institute, in a piece dated August 25, 2019, as sales and marketing expenses divided by the number of new customers. One division. The interesting half is not the formula, it is what the same page puts into the numerator:

“Sales and marketing expenses are the advertising and marketing spend, commissions and bonuses paid, salaries of marketers and sales managers, and overhead costs related to sales and marketing over the measurement period.” (Corporate Finance Institute)

Advertising spend. Commissions. Salaries, plural. Overhead. Every line item in that numerator is a thing a department has. Read it against your own shelf and the total comes to roughly zero, which the formula will happily report as a CAC of zero, which is the most flattering and least useful number in this course.

LTV — lifetime value — is the other side: the total profit one customer is expected to produce over the whole relationship. Its common form is average revenue per customer, times gross margin, divided by churn. Two of those three inputs are rates averaged over a base, and that is the assumption worth holding onto for the next few paragraphs.

The ratio between them — LTV divided by CAC — is then offered as a single verdict on whether the business works. It is the most quoted number in software and the one this lesson will spend the most time taking apart.

CAC when the currency is your own hours

Here is the version of acquisition cost that actually describes your shelf. You spend eight hours writing an article aimed at a query a buyer is already typing. Three months later it has brought in four customers. Nothing appeared on a card statement. There was no campaign, no agency, no commission, no salary. The standard formula’s numerator is empty and its answer is that those four customers were free.

They were not free. They cost eight hours, which is roughly two weeks of the evenings you actually have, and those evenings had other things they could have been. That is a real acquisition cost paid in a real currency, and it is invisible to every instrument in the previous section.

That framing is this course’s own construct, not a finding. I went looking for a rigorous source that treats hours as CAC’s native unit of account and did not find one. What exists is mainstream content that converts founder time into dollars at an assumed rate and folds the result into the ordinary formula — HubSpot’s own guide to calculating CAC for startups lists “founder’s time spent on sales” as a cost component, warns that leaving it out causes you to underestimate CAC, and then prices it at an assumed $50 an hour. That is worth knowing as corroboration that the omission is a recognised problem even inside vendor content. It is not a source for the hours-native version, and HubSpot is a company selling the sales and marketing software its own example counts as a cost line, which is worth saying out loud before treating its worked example as neutral.

Two reasons to keep the hours undiluted anyway. First, hours are the binding constraint on this whole project — you can find another $50, and you cannot find another Sunday. Second, an hours-denominated CAC is directly comparable to the maintenance number already in your ledger, because that one is measured in hours too. Dollars would put the two most important costs of a project into different units for no reason but convention.

Why LTV needs a churn number and a stated horizon

LTV has a worse problem than CAC, and it is not that the inputs are hard to get. It is that the formula, run honestly, often returns infinity.

Divide revenue per customer by churn and you are computing the value of a relationship that runs forever, weighted by how likely it is to end each month. Push churn toward zero — which is what a good, boring, low-maintenance product does — and the denominator goes to zero and the answer goes to the moon. A product with 1% monthly churn at $9 a month is reported as being worth $900 per customer, which is a claim that the average customer stays a little over eight years, on a product that has existed for four months.

This is not an outsider’s objection. David Skok, who popularised the ratio, wrote a whole follow-up piece with Stan Reiss on exactly this defect:

“The old formula that everyone uses for customer lifetime value (LTV) — average gross profit per customer divided by churn — ceases to work properly when you have very long customer lifetimes and negative churn. LTV can become infinite, which clearly doesn’t reflect reality.” (David Skok and Stan Reiss, forEntrepreneurs, published 2015, revised 2019)

Their fix is a discounted cash flow: future months still count, but each one counts a little less than the one before, because a dollar five years out is not worth a dollar today. It is a real improvement and it is worth being precise about what it does and does not do. It is still an infinite horizon. It just weights the far end down instead of cutting it off. Nowhere in that piece does the sum stop at a particular month.

Cutting it off is what this lesson tells you to do, and I will label that as the course’s own move rather than a citation, because I could not verify a primary source that truncates to a literal number of periods. The reason to truncate is not mathematical, it is epistemic: you have no evidence about month thirty-seven, so do not put a number there. Pick a horizon you can see the end of — twelve months is a defensible default for a project this young — compute LTV over only that stretch, and write the horizon down next to the number so that nobody, including you in six months, reads it as a lifetime.

The number that actually decides

Which brings us to the one figure worth putting in the ledger. The pricing lesson already ran this arithmetic on a single cost line: it took a measured support load, set it against a monthly revenue figure, and showed that doubling the customer count doubled the support hours too, so the rate never moved and growth just bought more of the same deal. That was an effective hourly rate computed on support alone. This lesson does one thing to it — it widens the denominator from support hours to every hour the project takes, acquisition included, and then treats the result as the project’s headline number rather than as a diagnostic for a pricing decision.

Effective hourly rate is monthly revenue, minus monthly direct costs, divided by the hours per month the project takes to run — maintenance plus whatever acquisition work you are still doing to keep it fed. That is it. One division, in units you have already measured for at least one project.

The calculator below is loaded with the same project the pricing lesson used, and the difference is only the denominator. Change nothing and read the second figure. Then put the support-only hours in and watch it move, and you will have the whole argument of this section in about four seconds.

The default is a project earning $300 a month that takes twenty hours of your life to run. That is $15 an hour. The same project, counted against support hours alone, looked like $50 an hour, and both numbers are arithmetically correct — they are answers to different questions. The narrow one asks whether the price funds the support. The wide one asks whether the project is worth your evening, and that is the question a ledger exists to answer.

The rate is also the only figure here that compares to anything outside the project. LTV compares to CAC and to nothing else. An effective hourly rate compares to a contracting rate, to a raise, to another project on the shelf, and to the value of an evening spent not working, which is a real alternative with a real price even though nobody invoices for it.

Why the venture-scale ratio is the wrong instrument here

Now the rule you have absorbed without ever reading its source. It comes from David Skok, in SaaS Metrics 2.0, in a section headed “Is your SaaS business viable?”, and his actual sentence is:

“The best SaaS businesses have a LTV to CAC ratio that is higher than 3, sometimes as high as 7 or 8.” (David Skok, SaaS Metrics 2.0)

Read that again against the version you have heard. “3:1” is the industry’s shorthand, not his phrase, and the shorthand loses two things in the compression. It loses “the best” — this is a description of top performers, not a passing grade — and it loses “sometimes as high as 7 or 8”, which tells you the figure is a floor observed across a population, not a target. A rule of thumb repeated since 2013 without its own sentence attached is exactly the kind of thing to go and check, and checking it changes what it says.

Skok is a partner at Matrix Partners, a venture capital firm, and forEntrepreneurs is that firm’s publication. That is not a disqualification, it is context for what the instrument was built to do. The same site’s piece on when early-stage startups should calculate LTV:CAC is written by Jared Sleeper, also a Matrix Partners investor, who restates the rule as Skok’s and adds the caveat that matters most: the ratio only becomes meaningful once the growth process is repeatable and scalable, and calculating it too early — on deals closed through founder relationships and existing networks — produces a CAC with no predictive value. Both sources for this heuristic are investors at the same firm, which is worth naming plainly: the canonical case for the number is one firm restating its own figure.

Skok pairs the ratio with a second test in the same section — that “many of the best SaaS businesses are able to recover their CAC in 5-7 months”, and that “the profitability is anemic if the time to recover CAC extends beyond 12 months”. Put the two together and the purpose is unmistakable. These are not tests of whether a product is worth building. They are tests of whether it is safe to pour money in faster. A high ratio and a short payback period say: the acquisition machine returns more than you feed it, so feed it more.

Which is why it does not transfer, in four specific ways:

• There is no capital to deploy. The ratio’s answer is “spend more on acquisition”. You have no acquisition budget, so the instrument’s output is an instruction you cannot follow, and an instruction you cannot follow is not a decision.
• CAC in hours breaks the arithmetic. LTV is in dollars. Your CAC is in hours. The ratio is dimensionless only because both sides are money; put hours on one side and it stops being a ratio and starts being a conversion rate you invented.
• The payback test measures the wrong scarcity. Recovering cash in five months matters when cash is what runs out. What runs out for you is Sundays, and no amount of recovered cash returns one.
• It has nothing to say about your alternative. A project can post a ratio of 9 and still be a bad use of the evening, because a healthy ratio on a tiny base is a small amount of money moving efficiently. The ratio cannot see the contracting work you turned down to do it. The hourly rate can.

Put a rate on the project you are pursuing

Your ledger has no revenue actuals in it, and this exercise does not need any. It needs a price you already defended, a customer count you can argue for, and a maintenance number you already measured.

What this does not cover

There is now a rate on the pursued project and, if you have two in pursue, a comparison between them. What there is not is a threshold — the rate at which you would actually stop. And the reason to write one down now, while the number is fresh and abstract, is the same reason the triage module made you commit to a verdict with a date rather than deciding later: the hours you have already sunk into a project are excellent at arguing on its behalf, and they get better at it every month. Choosing the number that ends something, before that argument starts, is what comes next.