Size the UK market for a paid meal-planning app, and tell me whether you would build it.

How a sizing case is marked

Nobody in the room knows the answer, and the interviewer is not checking your figure against a key. They are watching four things: whether you pin the question down before calculating, whether each assumption is stated separately so it can be argued with, whether the arithmetic is clean enough to follow in your head, and whether you end with a decision rather than a number. Two candidates can produce estimates a factor of three apart and score identically, provided both can say which assumption drove the difference.

The single most common way to fail is to be vague about the quantity being estimated. Announce it in one sentence. Here I will estimate annual consumer subscription revenue available in the UK to all meal-planning apps combined, at today's behaviour, excluding advertising and excluding grocery commissions — both of which I will bring back at the end because they turn out to matter more than the subscription line.

Pin the question down

Three clarifications are worth making out loud before any arithmetic, because each changes the answer by more than the estimation error.

The unit is a household, not a person, because meal planning is done once for everyone who eats at the table. The revenue is a subscription rather than a one-off, so the annual figure is the recurring one. And I am sizing the market that exists rather than a market a very good product might create; if I wanted the second number I would have to make a claim about behaviour change, and I would flag it as a claim.

I will work top-down from population, then check the result bottom-up from implied penetration. Working in only one direction is how sizing answers end up two orders of magnitude wrong without anyone noticing.

The population chain

Every line below is an assumption I would invite the interviewer to change. The two population figures are the only ones I would defend as roughly factual; the percentages are judgements.

Step	Assumption	Result
UK population	~67 million	67m
Households	average ~2.4 people per household	~28m households
Cook most evening meals from scratch	50%, the rest lean on ready meals, takeaway or eating out	14m
Plan meals deliberately in advance	30% of those — most people decide on the day	4.2m
Would use a phone app rather than a note, a notebook or memory	40%	1.7m
Would pay rather than use a free tool	15%	~255k households

So roughly a quarter of a million UK households are plausibly willing to pay for this at any one time. Now price it. A consumer utility subscription in this category sits at a few pounds a month; take £3 a month, so £36 a year.

255,000 households  x  £36 / year   =  £9.2 million per year

That is the whole UK consumer subscription market for meal planning, shared among every app in the category. If a category leader took a third of it, that is around £3 million a year of revenue.

Check it from the other direction

Before I believe £9 million I want an independent check, and the cleanest one is implied penetration. A quarter of a million paying households is just under 1% of all UK households. Is that high or low for a non-essential utility app? It is at the optimistic end: paid consumer utilities generally reach a fraction of a per cent of a national population, and 1% of households would make this one of the more successful paid consumer apps in the country. That tells me the £9 million is a ceiling rather than a base case, and if anything I have been generous.

The second check runs on price. If I had assumed £8 a month rather than £3, revenue would be £24 million, so the answer is highly sensitive to price — and a higher price would cut the 15% willingness-to-pay figure, probably by more than the price rise gains. That interaction is worth naming, because a candidate who flexes one assumption without noticing it moves another has not really understood their own model.

The assumption the answer is genuinely most sensitive to is the 15%, and it is also the one I have least evidence for. Halving it to 7.5% gives £4.6 million; doubling it to 30% gives £18 million. Everything else in the chain moves the answer less. So if I had one week of research, I would spend it there — a paywall test on a free version, or a price-sensitivity survey against people who already plan meals, not against a general audience.

Turn the number into a decision

A total addressable market of under £10 million a year, shared among incumbents, is not a venture-scale business and probably not a business worth a dedicated team inside a larger company either. That conclusion is the point of the exercise, and it arrived from the arithmetic rather than from taste.

So the recommendation is not to build this as a standalone paid consumer app, and instead to ask where the money in this behaviour actually sits. Somebody planning next week's meals is deciding a grocery basket, and the basket is two orders of magnitude larger than the subscription. Take £90 a week of grocery spend per household, so about £4,700 a year. If the app converted the plan directly into an online order and earned 3% on it, then even 100,000 households ordering half their groceries through it produces:

100,000  x  £4,700  x  50% online  x  3%  =  £7.0 million per year

Comparable to the entire subscription market, from a third of the households and without charging anyone. And unlike the subscription line, it scales with basket size and with online grocery share rather than with people's tolerance for another £3 a month. That reframing — same behaviour, different revenue line — is the answer I would give if asked whether to build it: not as a paid app, but as an acquisition and basket-building surface for a grocery retailer or delivery platform, where the sizing question becomes basket uplift per active household rather than subscribers.

I would also say plainly what I have not sized: whether a retailer would pay for it, what it costs to acquire a household, and whether the plan-to-basket conversion is anywhere near 50%. The estimate above establishes that the consumer subscription route is too small to be interesting, which is a real conclusion, and it does not establish that the retail route works.

Where sizing answers come apart

The failure that ends rounds fastest is compounding percentages without pausing. Five multiplications of numbers you invented produce a figure with no error bar and enormous variance, and a candidate who states £9.2 million with a straight face has told the interviewer they do not understand their own arithmetic. Say the range. Say which assumption owns most of it.

The second failure is subtler and it is the one this case is built to expose. Candidates finish the multiplication, announce the number, and stop — as though the deliverable were the estimate. It never is. The estimate exists to support a decision, and here the decision reverses on it: the number is not big enough to justify the product as specified, which should send you looking for a different buyer or a different revenue mechanism rather than a bigger funnel. An interviewer who has to prompt you with "so would you build it?" has already marked the answer down, because in the job nobody prompts you.

A third, smaller thing: keep the arithmetic in round numbers. 67 million, 28 million, halve, take a third, take 40%, take 15%. If you cannot follow your own calculation without a calculator, neither can the interviewer, and the value of the whole exercise is that they can watch you think.

The number is not the deliverable. Here the arithmetic says the consumer subscription market is too small to be worth a team, and that conclusion is the answer — a sizing case you finish without a recommendation is unfinished.