Two minutes of arithmetic now decide whether I let myself get interested in an idea
Two numbers now decide whether I let myself get interested in an idea, and both take about a minute. I wish I had been running them years earlier.
The first is division. At a flat monthly price, the customer count my target income needs is fixed the moment I choose the price — 29 a month against a 3000 a month target is 104 customers, every month, net of churn, forever. Nothing about the product changes that number. Only the price does, and doubling the price halves the count, which is why pricing power stopped being an afterthought for me.
The second is the one I never used to run. Every customer costs support time. At 15 minutes each per month, those 104 customers are 26 hours a month — about 6 a week, before a line of code exists.
The bands that matter for one person: under 2 hours a week is background noise, 2 to 8 is a real share of your build time, over 8 and support is the job. The example above sits in the middle band, and the middle band is more uncomfortable than it sounds — sustainable, and quietly enough that the second product never happens.
The thing I actually got wrong for years is that they fight. Lower the price and I need more customers, which is more support. Raise it and I need fewer — but a higher price means a buyer with a budget, usually a business, and business customers need more support each, not less. Both obvious moves trade one constraint for the other.
Which leaves three shapes that genuinely work: high price and low touch (hardest to find, best to own), low price and near-zero touch (only if acquisition is nearly free), and high price with high touch, which is a consultancy with software attached. That last one can pay very well. It is just not a business you can sell, and I know people who found that out late.
Neither number tells you whether anyone wants it. That still costs a real test. But most bad ideas are visible before that point, for the price of a minute of arithmetic: https://whittleos.com/guides/micro-saas-ideas
The arithmetic is useful, but I reckon the support average needs one more split.
Fifteen minutes per customer per month sounds manageable when spread evenly. In reality, support often arrives as onboarding time for new customers, routine help from the installed base, and occasional incidents that pull several customers in at once. A six-hour average week can still become an eighteen-hour launch or outage week.
For a solo founder, the dangerous number may be the peak rather than the mean. I’d want to estimate onboarding minutes per new customer, steady-state minutes per active customer, and the worst plausible support spike. That shows whether the business merely consumes time or can unexpectedly take over the week.
That split lands on my own tool, so let me concede it properly: what mine produces is hours per hundred users — a mean, with a per-category breakdown of what the tickets are and which ones a help page could deflect. You can read the onboarding share off the categories, which is something, but there's no peak number anywhere in the output, and peak is the one that decides whether a solo founder ships anything that week.
There's a second reason the mean misleads, on top of yours. Onboarding load scales with the rate of new customers, not the count — so the heaviest support weeks are your best sales weeks. The mean quietly promises that support and selling take turns, when in fact they arrive together, and the week you most want free is the week it consumes. The incident term is worse in a way that's structural: it's the one place where customers are not independent, so averaging over more of them doesn't smooth it. One outage is N simultaneous tickets from people who all expect an answer now.
Your three numbers are the right shape because each has a different driver — growth rate, installed base, and a correlated event. Rolled into one figure, a business with a steady trickle and one with a flat calm broken by eighteen-hour weeks score identically, and only the second one quietly takes the founder's month.