The situation
Kuwait has plenty of diet meal subscription providers. Signing up for one is easy. Staying with one is the problem.
The pattern is familiar to anyone who has tried: the first week is great, the second is fine, and by the third you're looking at the same rotation of the same kitchen and quietly losing interest. People don't abandon their diet because the food is bad. They abandon it because it's the same.
Wjbti attacks the problem at its root. One subscription gives the subscriber access to multiple providers — so they can eat from a different kitchen each day, choosing as they go. Same commitment, same single payment, completely different experience week to week.
For providers, it opens a shared demand pool they could never reach alone. For subscribers, it removes the single biggest reason people quit.
The hard part: an MVP that couldn't be minimum
Most products can launch with a slice. You ship the core, watch how people use it, and add the rest.
Wjbti couldn't. The value of the product is the complete cycle — subscribe, choose meals, receive them, repeat — and a cycle with a missing link isn't a smaller product. It's a broken one. A subscriber who can't pick tomorrow's meal, or whose delivery doesn't arrive, hasn't experienced a partial version of Wjbti. They've experienced a failure.
That meant the first release had to carry the entire loop:
- Subscriptions and payments — plans, billing cycles, renewals, and everything that happens when a payment doesn't go through
- Providers — onboarding, capacity, menus, and the operational reality of multiple independent kitchens serving one shared subscriber base
- Meals — catalogue, nutrition information, availability, and the cut-off after which tomorrow's kitchen can no longer change what it's cooking
- The calendar — the spine of the product, where a subscription becomes a specific meal from a specific provider on a specific day
- Delivery — the moment everything upstream is judged on
Five systems, each substantial, all of them required before a single real subscriber could be served properly.
Where the real complexity lived
Building those five systems was work. Making them behave sensibly when a subscriber does something unexpected was the actual engineering problem — and it's the part that decides whether a subscription product feels trustworthy or fragile.
Consider what looks like a trivial feature: pausing a subscription.
A subscriber pauses on a Tuesday. What happens to the meals already scheduled for the rest of the week? Do the paused days get returned to them at the end, or are they lost? What does the provider see — and how late is too late to cancel an order a kitchen has already planned around? When the subscriber resumes, does the calendar pick up where it stopped, or start fresh? Every one of those questions needs a definite answer, and none of them can be left to whatever the code happens to do.
Or take an even more common case: the subscriber simply doesn't choose. Life gets busy and tomorrow arrives with no selection made. The system can't leave them with nothing — they've paid — and it can't wait, because the kitchen needs to cook. So it has to choose for them, and choose well: something within their plan, from an available provider with capacity, that isn't what they ate yesterday.
Multiply that by every rare scenario a real subscriber will eventually produce — a provider going offline mid-week, a plan changed mid-cycle, a delivery that fails, a meal that sells out after selection but before cooking — and the pattern becomes clear. In a subscription marketplace, the edge cases aren't edges. They're the product.
The outcome
Wjbti works as a complete loop from day one, because it had to. One subscription, many kitchens, and a system that holds together when a subscriber pauses, forgets, changes their mind, or does something nobody predicted.
The variety is what subscribers notice. The scenario handling is why they stay.
