With a job, the binding constraint is not the idea — it is the week. Our own support calculator puts the ceiling of the middle band at 8 hours a week, and at 8 hours that is the entire budget, before a line of code or a single message to a buyer. So the useful question is not how to find time. It is which product shapes and which experiments fit inside a week you already spent.
What the bands look like from inside a part-time week
The support calculator sorts a product into three bands: background noise below 2 hours a week, a real share of your time up to 8, and past that support is the job. Those boundaries were set for a solo founder. Held against a part-time week, they read differently:
The two percentages are the share of your week consumed at the light ceiling and at the moderate ceiling, using the same boundaries the support calculator switches on. Bars are capped at a full week, which is why the top row is flat: it has already overflowed.
Read it downwards. At 10 hours a week a moderate product leaves you 2 hours for everything else; at 8 it leaves nothing; at 6 it does not fit at all. And support is the part that arrives last and never leaves — you do not feel it during validation, and by the time you do, the product exists.
What that means in customers
Bands are abstract until you put a number in them. Take $2,000 a month at $39: the calculator says 52 customers. At 12 support-minutes each per month, that is 2.4 hours a week — the moderate band, on a business that has not reached anything like a full-time income.
Two readings follow, and both are useful before you choose what to validate.
- The shape you validate is the shape you inherit. A product that needs a conversation per customer does not become self-serve later because you got busy. Pick the idea whose support curve fits the week you actually have.
- Higher prices buy time, not just money. Fewer customers for the same income is fewer support hours, which at this size is the difference between a business that fits and one that quietly takes over your evenings.
A two-week sprint that fits, with the hours added up
Here is 16 hours — 8 a week for 2 weeks — spent on finding out whether anyone wants the thing. The hours are computed from that budget rather than estimated, so the column sums to exactly what you have:
| Task | Hours | What it returns |
|---|---|---|
| Collect the complaints in writing | 3 | Either a file of real quotes, or the finding that there are none |
| Write the promise and the price | 2.5 | One sentence a stranger can act on, and a number beside it |
| Build one page with a real call to action | 4 | Somewhere the money or the commitment can actually land |
| Put it in front of people who already have the problem | 5 | Arrivals from a channel you can use again |
| Write down the bar before you look | 1.5 | A pass or fail you cannot argue with afterwards |
| Total | 16 | Your whole sprint |
An allocation of a stated budget, not a forecast — the shares are ours and the hours are derived from them. What is worth arguing with is the proportions: 25 per cent of the sprint goes on building anything at all.
That proportion is the whole design. Building is the task that expands to fill whatever time it is given and returns the least information per hour, so it gets the smallest slice that still produces something a stranger can act on. The largest slice goes to distribution, because on a part-time budget the most likely outcome is not rejection — it is silence from an audience that never showed up.
The last row costs almost nothing and does the most work. Write the number that means yes before you look at any results; afterwards, every number is negotiable.
What you give up by fitting it
Speed, mostly, and the ability to react. Two weeks of evenings is a slower test than two days of full-time work, and a slow test has more chances to be overtaken by something you cannot control.
You also give up depth. This sprint produces a yes or a no on one narrow question and nothing like a map of the market. That is the right trade at this budget — a part-time founder's most expensive mistake is not a wrong answer, it is a vague one that takes another month to resolve.
And it does not fit every idea. If the honest support estimate already puts you at the moderate ceiling, the sprint above is not the problem and no schedule will fix it. Change the product shape or change the price, then come back.
The short version
- At 8 hours a week, our own moderate support ceiling is the entire week. Support is a design constraint at this size, not a cost to optimise later.
- $2,000 at $39 means 52 customers and 2.4 support hours a week. Fewer, better-paying customers buy back time.
- Budget the sprint in hours and make the column add up. Ours spends 25 per cent on building and the largest share on getting in front of people.
- Write down the bar before you look at the results. It is the cheapest line in the plan and the only one that protects the rest.