Support is the thing founders plan to deal with later. For one person it is not a cost line, it is a constraint on what the product can BE — and unlike almost everything else you want to know before building, it is decidable now, because the answer follows from the workflow you are describing rather than from usage data you do not have.
The scale runs the other way
One design decision to get straight first, because it is the only part of this analysis a reader can read backwards. The scale runs the other way. Every other mode scores upward, and this one inverts, because the good outcome is the small one: the best verdict maps to 85 and the worst to 25.
Say it plainly: a HIGH verdict is bad news. If you skim one number off this and it is high, you have found the problem, not the endorsement. We render that chart from the projection the scorecard actually uses, so the polarity on the page cannot drift away from the polarity in the product — which is the only real defence against a chart that silently inverts after a refactor.
The instruction pushing back
The contract also carries an instruction pushing the other way, and it is worth knowing about: the estimate must not be over-pessimistic, on the stated grounds that over-pessimism wrongly kills viable ideas. A gate tuned to find support problems everywhere would find them everywhere, so it is explicitly told not to reach.
The arithmetic
Now the arithmetic that makes this decide the product's shape rather than its cost structure. Fix the customer count at 100 and sweep the minutes each one takes per month. 5 minutes is 1.9 hours a week. 30 minutes is 11.5 hours a week. 60 minutes is 23 hours a week.
That is the whole argument. At 30 minutes per customer per month — one real exchange, not a crisis — support alone is more than a day of every week at a customer count most solo products would call a good start.
The two distinctions that decide it
Two distinctions do the work of deciding which row you are on, and neither needs usage data. First, is a ticket DEFLECTABLE: can docs, onboarding or the product itself answer it, so you fix it once — or does it need you, every time, forever. Second, customisation risk: does everyone get the same product, do some clients need a setting nobody else uses, or does each client need work only you can do. The third rung is the definition of an agency, and nobody arrives there on purpose. You arrive one accommodating yes at a time.
Where this ranks, measured
Where this ranks among ways an idea dies, measured rather than asserted: across 706 killed candidates on 23 real runs, hands-on support load was named in 187 of them — 26 percent, second only to the missing documented problem. Measured on 2026-09-06, on our own accounts, so it describes our gate rather than a market.
The practical consequence for a design decision: every feature that needs explaining is a recurring cost priced in your weeks, and the cheapest support work is the kind you do once in the product rather than every time in an inbox.
The sweep and both ladders: https://whittleos.com/guides/will-my-saas-be-support-heavy
Top comments (0)