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. The answer follows from the workflow you are describing, not from usage data you do not have.
There is one thing 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 here scores upward: a better answer is a higher number. This one inverts, because the good outcome is the small one.
low — Self-serve. Tickets are rare and mostly answerable by docs.85medium — A real share of the week, survivable with SOPs.55high — High-touch. Support is the product's actual shape.25Read from the projection the scorecard uses, so the polarity on this page cannot disagree with
the polarity in the product. A low verdict is the best one
available here.
Say it once more plainly: a high verdict is bad news. If you skim one number off this analysis and it is high, you have found the problem, not the endorsement.
The contract also carries an instruction that pushes 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.
What a support minute costs when there is one of you
The reason this decides the product's shape rather than its cost structure is arithmetic. Fix the customer count at 100 and sweep the minutes each one takes per month:
Minutes per customer, per month | Hours a week | Band |
|---|---|---|
| 5 | 1.9 | light |
| 10 | 3.8 | moderate |
| 15 | 5.8 | moderate |
| 30 | 11.5 | heavy |
| 60 | 23 | heavy |
From the free support-hours calculator at 100 customers. The bands are calibrated to a solo week, not to a support team's.
The row to look at is 30 minutes: 11.5 hours a week, which is most of the time a nights-and-weekends founder has in total. Half an hour a month per customer sounds like nothing and is a part-time job at 100 customers.
Notice the shape of that. The distance from 5 minutes to 30 is not a rounding difference in your calendar — it is 1.9 hours a week against 11.5. This is why the question is a design question. You are not choosing how much support to provide; you are choosing a workflow, and the workflow chooses the number.
The call that matters more than the verdict
The distinctive judgement in this analysis is not the three-way level. It is a single boolean the contract calls the custom-agency trap: service work disguised as a product. Bespoke deliverables, per-client customization, manual fulfilment behind a signup page.
The contract says to bias toward catching it. That is an unusual instruction and you should read it as what it is — a deliberate asymmetry, accepting some false alarms because the failure it prevents is a year spent building an agency you did not want and cannot sell. When the flag fires it must name the reason, so you can disagree with the specific claim rather than with a label.
The trap has a leading indicator, graded separately:
low customization riskmedium customization riskhigh customization riskHow much per-client bespoke work creeps in. The third line is the definition of an agency, and nobody arrives there on purpose — you arrive one accommodating yes at a time.
That drift is the mechanism, and it is made of reasonable decisions. Each individual request is small, the customer is paying, and saying yes is easier than the conversation where you say no. Twelve of those and the product is a delivery pipeline with your hands in it.
The lever you actually have
Every ticket category gets graded on one property, and it is the only one you can change by building differently:
Deflectable means docs, onboarding or the product can answer it. The distinction is per category, not per ticket.
A deflectable category is a fixed cost: you write the doc, change the empty state, rename the confusing button, and it stops arriving. A non-deflectable one is a subscription you pay in hours, and it scales linearly with the customers you were hoping to add.
So the useful question is not "how many tickets will I get". It is which categories need a human, and can I remove them from the product. The analysis is asked for that list explicitly — things to deliberately not support — because a scope cut is a support fix that ships before the ticket exists.
How often this is the thing that ends an idea
We can put a number on how much this matters, from our own gate rather than from opinion. Across 23 real discovery runs measured on 2026-09-06, 706 candidates were killed at triage, and support burden was named in 187 of them — about 26% of all kills, second only to a missing pain anchor at 438.
The three most common reasons a candidate dies, of 706 kills across 23 runs. A candidate can be killed for more than one reason, so these do not sum to the total.
The limit on that, stated before anyone quotes it. Those 23 runs are all from the founder's own accounts — there is no customer discovery data in production. So this is a measurement of how our gate behaves, not of how the market behaves. It supports one claim: when a gate built to find the reasons a solo product fails looks at a few hundred candidates, support is the second thing it finds. Read it as a statement about where the risk concentrates, and check the pain anchor first anyway, because that is where the bigger number is.
Deciding it before you build
- Describe the workflow, not the product. Write out what happens between a customer paying and the customer getting what they paid for. Every step with your hands in it is a support minute forever.
- Sort your expected questions into deflectable and not. Be honest about which ones a doc really answers. "They can read the guide" is a wish; "the empty state does it for them" is a fix.
- Watch the first bespoke yes. Not the tenth. The first one is the decision; the rest are consequences.
- Run the number. Take your realistic minutes-per-customer to the support-hours calculator and look at the week that comes back at the customer count your price actually requires. If those two do not fit in the same week, the product needs a different shape, not a better inbox.
The short version
- The scale inverts. Low is the good verdict here, and a high number is the finding, not the pass.
- At 100 customers, 30 minutes each per month is 11.5 hours a week — a part-time job hidden inside a plausible number.
- The real call is the custom-agency trap, and the contract deliberately over-detects it, because the cost of missing it is a year of bespoke work.
- Deflectable is the only lever: a category a human must answer scales with your customers, and cutting it from scope is a support fix that ships before the first ticket.
- On 706 killed candidates from 23 of our own runs, support burden was named 187 times — second most common. Our gate, not the market.