Ongoing Foods is a daily meal-subscription and delivery service. We built the whole engine behind it — the API that powers the Flutter mobile app, the recurring-subscription logic, and the web admin that vendors use to run the kitchen. It's live on the App Store and Google Play.
The problem: a subscription kitchen is a daily operation
A meal-subscription business isn't like a normal store. The same customers need food every day, on a schedule — and every day someone has to turn "who's subscribed" into "what we cook and deliver today." Do that by hand and it falls apart fast:
- Regenerating each day's deliveries from the list of active subscriptions — tedious and error-prone.
- Customers who travel or skip a day — someone has to track pauses and one-off skips so meals aren't cooked and wasted (or missed).
- Coordinating delivery timing across customers and slots.
- Onboarding mobile customers without the friction of passwords and sign-up forms.
- Keeping the kitchen and delivery in sync as orders move through the day.
The customer app
The mobile app talks to a token-authenticated API we built for it. From the customer's phone:
- Passwordless login. Sign in with a phone number and a one-time code — no password to remember, no email required.
- Browse the menu. Menus and dishes with images, served fast from the API.
- Subscribe to a plan. Pick a menu over a date range on a daily or alternate-day schedule — then pause and resume anytime, or skip a single day without cancelling.
- One-time orders alongside subscriptions.
- Saved addresses with map coordinates and a default, so checkout is one tap.
- Push notifications that keep customers updated as their order moves.
The subscription engine
This is the heart of it. A scheduled job runs automatically and turns active subscriptions into the day's real delivery orders — respecting each customer's schedule, pauses, and skips. It's built to be safe under load: idempotency keys and row-level locking mean it never double-creates or double-charges, even if it runs twice. The daily "who gets what" that used to be manual just happens.
The vendor admin
Running the business happens in a web admin we built with Vue and Inertia:
- Menus, dishes and categories — the catalog the app reads from.
- Delivery slots the team defines and attaches to orders.
- Order operations — accept or reject orders and move them through to out for delivery, with payments recorded (Cash, COD or UPI).
- Multi-vendor by design. The platform is team-based, so more than one food brand can run on it, each with its own menus, slots and orders, and staff roles (Owner, Admin, Member).
Built to run a real business
Because this handles real customers, money and daily deliveries, it's engineered for correctness: a status for every state (orders, subscriptions, deliveries, payments), idempotency to prevent duplicates, per-resource access policies, and a broad automated test suite covering auth, orders and subscription generation. It also ships the store-compliance pieces a published app needs, including in-app account deletion. The result runs live on iOS and Android.
Want an app like this?
We build mobile apps and the backends that run them — end to end, at a fixed price. Tell us what you're building, or see how we price projects.
