madealone
← writing3 min

The economics of one

A solo company runs on different math than a startup. Lower revenue is survivable; high overhead is not. Here is the spreadsheet I actually live by, and the three rules that fall out of it.

businessfinance

Most business advice is written for companies with employees. That advice is quietly poisonous for me, because every line of it assumes I can convert money into capacity by hiring. I can't. When you are the entire company, the constraint is never capital — it's attention, and attention does not raise rounds.

So the math is different in three specific ways. Once you internalize them, most of the hard decisions answer themselves.

1. Revenue per hour, not revenue per month

When you're a team, you grow by hiring. A new engineer adds throughput, and your job is to find revenue that justifies the headcount. When you're alone, you cannot hire your way out of anything. The only resource that scales is your own focused hours — and there are maybe 1,500 of those in a year if you also intend to have a life.

A product that nets $4k/mo on eight hours of upkeep beats one that nets $9k/mo on thirty. The second one isn't a business. It's a job you accidentally hired yourself for.

me, after killing the $9k one

That reframing changes what "good" looks like. The number I optimize is not MRR. It's MRR per focused hour.

2. Margins are oxygen

Investors will tell you margins are something to fix later. They're wrong — for me. I don't have a runway someone else funded; I have one I re-earn every month. A 92% gross-margin product survives a quiet quarter. A 40% product fires me the moment growth stalls.

Watch out

Every dependency that takes a percentage of revenue is a tax on your ability to take a slow week. I refuse to resell anything I don't own, because reselling is borrowing margin I have to pay back in volume — and volume means support, and support means hours.

3. The maintenance tax

Every live product carries a monthly cost in attention even when nothing about it changes: bug reports, billing edge cases, a dependency CVE, a customer who replied-all to a receipt. Call it the maintenance tax.

My rule of thumb: budget ~10% of a product's monthly revenue as upkeep hours you don't get to choose.

$1k MRR
~4 hrs/mo upkeep
10%
revenue I reserve for maintenance
$80/hr
notional cost of my own time
2
products I've sunset so far

When the maintenance tax exceeds the revenue, you are literally paying a customer to keep using your software. That's the signal to raise prices or pull the plug.

The spreadsheet, honestly

These are the only columns I track per product. No vanity metrics, no funnel — just the five numbers that tell me whether a thing deserves to stay alive:

  • MRR — monthly recurring revenue, net of refunds
  • Hours — focused hours that month, support included
  • MRR/h — the one number I actually look at
  • Stack — infra + SaaS the product depends on
  • Net — MRR minus stack minus $80/h for my time

Note

When Net goes negative two months running, I either raise the price or sunset the product. I have never regretted doing either. Both times I killed something, a week later I'd forgotten it existed.

What this changes in practice

The three rules collapse into a handful of stubborn habits:

Your company of one doesn't need to look like mine. But it does need a spreadsheet, and the spreadsheet needs to be honest enough to fire a product you're emotionally attached to. Mine has. That's how I know it works.