Five products in one food platform, and an AI that helps you choose
Before, and after
An app that shows you what is popular
- Food apps optimise for what sells, which is not the same as what suits you.
- The decision — what should I actually eat — happens outside the app, badly, while you are already hungry.
- Ordering is a separate step from deciding, so the advice and the checkout never meet.
Something that helps you decide, then orders it
- The AI is the front door: it talks through what suits you and what does not before anything is listed.
- You order inside the same flow, so the decision and the checkout are one action.
- Live in public — on the App Store and at lazyeat.in — so the claim is one you can check by opening it.
What they were up against
Ordering food is a decision people make several times a week and mostly make badly — the app shows you what is popular, not what is good for you, and by the time you are hungry enough to open it you are past caring. We wanted the deciding part to be the product, not the browsing.
What we shipped
An AI that helps you work out what to eat — what will suit you, what will not, and why — and then lets you order it without leaving that conversation. Underneath it that is five separate products: apps for customers, riders and restaurant staff, plus dashboards for the restaurant and for us.
What went wrong, and what we did
The hard part was the count, not any one piece. Five surfaces share one domain model, so a change to how an order works is a change in five places, five release cycles and five sets of edge cases — and the whole thing only functions when all five agree. We scoped this as an app with some panels attached, and it is not: it is five products that happen to ship together. Anything similar we now scope as five.
What was asked for, and what was done
The brief in their words.
- A food delivery app people could order from.
- Something that helped a diner decide, not just browse a list.
What actually shipped.
- A customer app, a rider app and a restaurant app — three separate products, not three views of one.
- Two dashboards: one for the restaurant to run its own service, one for us to run the platform.
- An AI that talks through what suits you and what does not, then takes the order in the same flow.
- Money handled in integer paise throughout, so no total or payout is ever the result of floating-point arithmetic.
- Live on the App Store and at lazyeat.in.
Not in the brief. Proposed by us.
- Sequential rider dispatch rather than broadcasting an order to everyone at once — one offer at a time, so two riders cannot claim the same delivery.
- Geotagged proof-of-delivery photos, so a disputed drop has an answer instead of two accounts of it.
What keeps it safe.
- Rider and restaurant identity documents held in an AES-256 encrypted vault on Cloudflare R2, not in the application database.
- Delivery call and tracking connections use short-lived credentials minted per session rather than a shared secret.
- SMS and push delivered through dedicated providers, so no phone number is exposed to the client apps.
Pointed at customers and revenue.
- The AI is the front door, so the platform competes on the decision rather than on discounting.
- One flow from advice to checkout — no step where the diner leaves to think about it.
- Restaurants get their own dashboard, which is the reason to join rather than a fee to pay.
How lazyeat.in scores
Measured on 16 Oct 2026 with Lighthouse 12.8.2, the engine behind Google's PageSpeed Insights: three runs on mobile and three on desktop. This is a lab test rather than data from real visitors, so treat it as a dated snapshot, and run it yourself if you want a second opinion.
Mobile
- Performance
- 81
- Accessibility
- 87
- Best practices
- 100
- SEO
- 100
Performance ranged 79–81 across 3 runs; the median run is shown.
Desktop
- Performance
- 84
- Accessibility
- 87
- Best practices
- 100
- SEO
- 100
Performance ranged 82–95 across 3 runs; the median run is shown.
| Measure | Mobile | Desktop |
|---|---|---|
| First Contentful Paint | 3.1 s | 1.5 s |
| Largest Contentful Paint | 4.0 s | 1.6 s |
| Total Blocking Time | 0 ms | 0 ms |
| Cumulative Layout Shift | 0.001 | 0.003 |
| Speed Index | 3.5 s | 2.3 s |
Checks that still fail (mobile)
- Accessibility: 2 of 11 fail — Background and foreground colors do not have a sufficient contrast ratio.
- Best practices: all 14 pass
- SEO: all 8 pass
Largest savings still open (mobile)
- Eliminate render-blocking resources · Est savings of 1,370 ms
- Reduce initial server response time · Root document took 790 ms
- Properly size images · Est savings of 111 KiB
Talk to the founder, today.
WhatsApp, or leave a number and get a call back — usually the same day. No forms about budget, no sales team.