Founder story · 2013–2014 · CIS · iOS · Closed. A fully built content product with working per-user economics and a revenue model that could not grow.
Chefmates was an iOS cookbook built as an aggregator: recipes from established cooking blogs and food influencers, pulled into one mobile journey from discovery through to step-by-step cooking. It ran for about a year and reached 2,000 monthly active users.
The product was further along than a recipe list.
| Recipes | 600+ |
| Authors | 72 — of which 15+ were well-known names, plus aggregated blogs on top |
| Categories | 10 |
| Designed screens | 30+ |
Recipes came in three formats — plain text, photo, or step-by-step video. Every author and blog had its own page with bio, contact details, and links back to their blog and social accounts. Around that sat favourites, social sharing, a shop, and a shopping list.
The content supply cost nothing up front. More than 100 blogs and influencers contributed on revenue share — a percentage of sales instead of a licensing fee. Content cost scaled with revenue rather than preceding it, which is how the cold-start problem that kills most recipe apps got solved.
Search was the real engineering bet. The team studied more than 50 food applications and how people actually searched in them, then replaced category drilldowns with a single bar that took plain language: vegetables stew 15 minutes, healthy salad for breakfast, texan barbecue, Ella Martino recipes. Intent, duration, meal slot, cuisine, and author name through one input — years before that became the default expectation.
Thirty-plus designed screens, 600+ recipes, and a search bar that took plain language.
A recipe carried portions, cooking time, and calories up front, then ingredients and step-by-step instructions with the author credited and linked. A shopping list came out of the recipe and could be sent by email or SMS — and cleared by shaking the phone.
Every recipe listed its ingredients in full and credited the author with their own profile and recipe count. Content came from more than 100 blogs and influencers on revenue share, which is why a catalogue this size existed without a content budget.
Two monetisation models were tried, and both were one-off:
1. Selling cookbooks inside the app — a single purchase of a bundle of content. 2. Selling placement inside the aggregator — creators and brands paying to be surfaced.
Together they produced about $1,000 a month.
That number deserves a second look before it gets written off. Against 2,000 monthly active users it is $0.50 per active user per month — roughly $6 a year, from a content app in the CIS market. Per user, the monetisation was working.
The problem was that it could not grow with anything. People cook several times a week — the usage pattern is recurring — and both revenue models charged once. A user who came back every day was worth the same as a user who came back once. Revenue could only rise by adding new users, and the base was 2,000.
Paid placement had the second problem: it is priced off audience size. At 2,000 monthly actives there was no inventory worth buying, which capped that line before it started.
The model that fit the behaviour was subscription, and it was never tried. Not for a strategic reason — we simply did not get to it. We were tired, and after about a year we closed the company instead.
| Claim | Evidence |
|---|---|
| Content supply can be free at the start | 100+ blogs and influencers on revenue share; 600+ recipes from 72 authors |
| The product was fully built, not a prototype | 30+ designed screens; text, photo, and video recipe formats |
| Search was researched, not assumed | 50+ competing food apps studied before designing a single natural-language search bar |
| The product held an audience | 2,000 monthly active users |
| Per-user monetisation worked | ~$1,000/month from 2,000 MAU = $0.50 per active user per month |
| One-off models do not compound with recurring usage | Revenue independent of how often a user returned |
| Ad-style placement needs scale to price | 2,000 MAU produced no inventory worth buying |
Match the revenue model to the frequency of the behaviour before optimising anything else.
There is a second lesson underneath the first, and it is less comfortable: the reason subscription was never tried is that the founders ran out of energy before they ran out of options. Founder exhaustion is a real failure mode, and it does not appear in any model. It looks like a strategy decision afterwards. It was not one.
Revenue share. More than 100 cooking blogs and influencers — 72 credited authors, 15+ of them well known — supplied recipes in exchange for a percentage of sales, so content cost scaled with revenue instead of preceding it. The catalogue reached 600+ recipes across 10 categories.
Per user, it did — about $1,000 a month from 2,000 monthly actives is $0.50 per active user. What it could not do is grow. Both models charged once, so a user who returned daily was worth the same as one who returned once, and revenue could only rise by adding new users.
No strategic reason. The team ran out of energy before it ran out of options and closed the company after about a year. That is the honest answer, and it is the more useful half of the lesson.
Search. Instead of category drilldowns, one bar accepted plain-language queries mixing intent, time, meal and author — `vegetables stew 15 minutes`, `healthy salad for breakfast`. It came out of studying more than 50 competing food apps and how people actually looked for recipes in them.
Charge on the same cadence as the behaviour. If people come back weekly, one-off purchases will cap revenue no matter how good the content is — and paid placement needs an audience large enough to be worth buying.
If you would rather talk it through before sending a brief, book a short routing call and we will point you to the right next step.
