{"id":6392,"date":"2026-07-24T09:00:00","date_gmt":"2026-07-24T07:00:00","guid":{"rendered":"https:\/\/storiesonboard.com\/blog\/calendar-timed-food-delivery-app-backlog"},"modified":"2026-07-27T22:46:05","modified_gmt":"2026-07-27T20:46:05","slug":"calendar-timed-food-delivery-app-backlog","status":"publish","type":"post","link":"https:\/\/storiesonboard.com\/blog\/calendar-timed-food-delivery-app-backlog","title":{"rendered":"Designing a calendar-timed food delivery app: from a raw idea to a 111-story backlog"},"content":{"rendered":"

I wanted to see how far I could get from a completely raw product idea to a real, living backlog in StoriesOnBoard by running it through the story map skills. Not as a demo: I wanted to find out where the process pushes back, and where it fills in things I wouldn't have thought of myself.<\/p>

The section breakdown below is deliberately generic \u2014 I'd mark the same points in any other use case.<\/p>

\n

Where this test came from<\/h2>\n

This experiment follows the skill-family setup described in Five Skills, One Backlog<\/a>. That earlier article explains why the workflow is split into discovery, story-map creation, gap analysis, refinement, and navigation. This article is the practical follow-up: what happened when I used those skills on a raw food delivery app idea.<\/p>\n<\/section>

1. The use case: what I was actually building<\/h2>

The idea was a food delivery app for people whose calendars are booked back-to-back.<\/p>

The insight behind it: for someone in meetings all day, the problem isn't that delivery is slow. It's that it's unpredictable. If you only have a 25-minute gap between two calls, food arriving "sometime in the next 40 minutes" is useless \u2014 it turns up mid-meeting and goes cold on your desk. These people know in advance exactly when they're free, which is unusual and exploitable. And there's a second, quieter job to be done: working out when you have to order so that the food lands in the gap rather than outside it.<\/p>

That's all I brought to the table:<\/p>

Food delivery app for a customer base with a lot of meetings, who know in advance when they're free. They can't tolerate imprecise delivery because they're only available in a specific window \u2014 so it matters that they know when to place the order for it to arrive exactly when it suits them.<\/p>

No personas, no scope, no business model. In theory, exactly the kind of input a generator would happily turn into a hundred forgettable user stories.<\/p>

2. Discovery: the skill asks first<\/h2>

It didn't generate. It said the problem and the target user were clear, then flagged that three decisions would produce materially different structures, so we'd settle those before building anything:<\/p>

What's the delivery model? Own courier fleet with partner restaurants? Aggregating existing services (Wolt, Foodora)? Or restaurants delivering themselves? How does the app know when the user is free? Calendar integration? A manually entered window? Both? Who places the order? An individual professional, a company team, or both?<\/p>

Those three questions were worth more than I expected. None of them is a matter of taste \u2014 each one changes the backbone. As an aggregator there's no courier- or kitchen-side scope at all; with an own fleet you need four different surfaces before a single meal moves.<\/p>

My answers: own courier fleet + partner restaurants, calendar integration (Google\/Outlook), individual professional (B2C).<\/p>

Transferable lesson: good discovery doesn't ask "what else would you like". It asks which decision changes the structure. Two or three questions, each a fork in the road.<\/p>

3. The uncomfortable question: how is this different from what already exists?<\/h2>

This is where it got interesting. With the structure sketched, it didn't start building \u2014 it logged an open risk:<\/p>

Wolt and Foodora already support scheduled orders. The switch test is unanswered: why exactly would someone move?<\/p>

That was uncomfortable because it was true. "Tell us when you want it" is not a gap in the market. When I asked about the unique value, it put three different bets in front of me \u2014 not three phrasings of the same one:<\/p>\n \n \n \n \n \n \n
Positioning<\/th>\n The unique value<\/th>\n The riskiest assumption<\/th>\n <\/tr>\n <\/thead>\n
The guarantee<\/td>\n We promise a window and refuse your order if we can't hit it<\/td>\n Will people accept "no" often enough for the promise to stay credible<\/td>\n <\/tr>\n
The backwards clock<\/td>\n We tell you when to order so it lands in your gap<\/td>\n Is the deadline the real pain, rather than the accuracy<\/td>\n <\/tr>\n
Calendar-native<\/td>\n Your calendar plans lunch, not you<\/td>\n Will people grant calendar access to a food app<\/td>\n <\/tr>\n <\/tbody>\n<\/table>

Its argument was that only the first survives the switch test: bets 2 and 3 make the incumbent experience nicer but give nobody a reason to leave. What you can't get anywhere is somebody being accountable for the window \u2014 and the reason nobody offers it is precisely that accountability is expensive.<\/p>

I picked 1 and 3. Combined:<\/p>

Your calendar picks the moment, and we guarantee the food lands in it \u2014 or we don't take the order.<\/p>

It immediately named the cost too: this carries two risky assumptions into the MVP at once, so the MVP can't be trimmed down to a thin test of a single thing.<\/p>

Transferable lesson: if a skill never asks what makes this better than the strongest alternative, you'll end up with a feature list rather than a product. This was the most valuable stretch of the whole process.<\/p>\n\n