GoServe roadmap

updated 01:03 · 77 of 220 stories done

Vision

Hot meals from our own kitchen. At your door in 25 to 35 minutes. Cash at the door. GoServe runs the kitchen, picks the rider, and carries the plate a short way. One pin code at a time. The first kitchen is live in Delhi.

Delivered

investor doorway site (letsdwelo.in) 2 done · 13 Oct to 13 Oct

  • Story: capture pre-registration and investor leads from the site
  • Story: Delhi as first city on the site, and a home for design tokens
architecture evolution and procurement plan 3 done · 13 Oct to 13 Oct

  • Story: architecture evolution page, components per phase, and Laya plan
  • Story: MVP 0 readiness, components refresh, options research
  • Story: deep ops research, MVP 0 setup decisions, phase gate
App foundation and build and deploy 4 done · 14 Oct to 14 Oct

  • Story: Scaffold the app (React, Vite, TypeScript, PWA, tokens)
  • Story: the checks job for app/ and the pre-commit hooks
  • Story: Dev deploy: push to dev publishes to Vercel goserve-app-dev
  • Story: Prod deploy: main publishes to Cloudflare Pages goserve-app
Data layer (Supabase) 2 done · 14 Oct to 14 Oct

  • Story: Schema: 7 tables and the legal-status rule
  • Story: Row level security, Realtime and the Delhi sample menu
Order API (n8n GS workflows) 3 done · 14 Oct to 14 Oct

  • Story: Place order and change status workflows (MAIN 01, SUB 11, SUB 12)
  • Story: Decide and logs workflows (SUB 13, SUB 14)
  • Story: Daily scorecard workflow (MAIN 90)
Screens (customer, kitchen, rider, ops) 5 done · 14 Oct to 22 Oct

  • Story: Customer screen: menu, cart, bill, place order
  • Story: Kitchen screen: live orders with Accept, Start, Ready
  • Story: Rider steps and live customer status through Delivered
  • Story: Ops screen: AI suggestion and metrics panel
  • Story: Role apps (customer, kitchen, rider, ops) as separate installable PWAs, one device first
Demo safety net 3 done · 14 Oct to 14 Oct

  • Story: Split view, own space per session and reset
  • Story: Autopilot that works in airplane mode
  • Story: Health check page (Supabase, n8n, Jev)
Monitoring and demo readiness 3 done · 22 Oct to 25 Oct

  • Story: UptimeRobot monitors for dev and prod
  • Story: 20 of 20 scripted runs, founder Android check and backup video
  • Story: Production release prep (prod database, app, workflows)
UAT v2 (feedback, delivered by hand, UAT numbers) 4 done · 22 Oct to 22 Oct

  • Story: S-B Feedback button inside the app
  • Story: S-C Delivered by hand, paid by cash
  • Story: S-C2 Web Push for the delivered prompt (after the demo)
  • Story: S-E UAT numbers in the 21:00 card and Ops panel (after the demo)
City data model 1 done · 25 Oct to 25 Oct

One database shape for a city: many kitchens with pin codes, customers, riders, admins, cancel.

  • Everything else needs one data model that holds many kitchens, customers, riders and admins.
Admin panel 3 done · 25 Oct to 25 Oct

The founder runs the system from `/admin/` in the PWA: kitchens, staff, menu with photos, orders, numbers.

  • The founder adds a kitchen and its people without touching the database.
  • Each kitchen's menu is managed by the founder, with real photos.
  • The founder sees the day and can stop a bad order.
Dispatch and riders 1 done · 25 Oct to 25 Oct

Riders have accounts, go online, share their location, and are assigned by rule; the assignment is saved on the order.

  • Each order goes to one rider, chosen by rule, and the rider sees only their own orders.
Kitchen operations 1 done · 25 Oct to 25 Oct

Kitchen staff mark a dish sold out and open or close the kitchen.

  • A kitchen controls what a customer can order right now.
Customer flows (functional) 3 done · 25 Oct to 25 Oct

A customer finds the kitchen by pin code, saves a profile, orders, tracks, cancels, sees history, signs out.

  • A refresh must not lose the customer's place.
  • A customer orders from a kitchen that serves their area.
  • The customer has an account-like experience on a cash order.
Notifications 1 done · 25 Oct to 25 Oct

Customers get a web push on placed, ready and delivered, even with the app closed.

  • The customer learns about the order without keeping the app open.
Synthetic city on prod 8 done · 25 Oct to 25 Oct

Synthetic kitchens and riders on prod for the owner's scale proof, with changing availability, one seed API and one reset API.

  • One n8n API seeds synthetic kitchens, riders and dishes from parameters and one resets them.
  • A scheduled tick moves synthetic riders and flips synthetic kitchens and dishes while the simulator is on.
  • The admin sets parameters, seeds, resets and switches the tick on and off, and sees counts.
  • When someone opens GoServe in Delhi, they see ten kitchens worth ordering from, the kinds we want to sign, each with a full menu at today's prices.
  • A customer on a real Delhi pin sees the demo kitchens and gets a rider, for every kitchen, the two old ones too.
  • An order on a demo kitchen moves like a real one: accepted, cooked, picked up and delivered by a moving rider.
  • A customer in East Delhi (pin 110092, the owner's own pin) has a kitchen close by, not one 8 to 10 km away.
  • When someone opens a demo kitchen's menu, every dish shows a real, good-looking photo.

You are here

26 Oct 01:03 India time

Next to start: Everyone can see which branch holds what, and every story has the labels it needs. #316

Milestones

MVP0 demo 18 Oct 19 of 19 · due 18 Oct · finished after its date
MVP 1 Golden path 4 of 7 · due 22 Oct · late by 4 days
MVP 2 Pilot ready 12 of 18 · due 24 Oct · late by 2 days
MVP 2.5 Pilot hardening 13 of 18 · due 26 Oct · due today
M0 Roadmap live 1 of 4 · due 26 Oct · due today
M1 MVP2 demo-ready (PWA, frozen) 0 of 7 · due 27 Oct · 1 day left
M2 Design v2 approved 0 of 10 · due 28 Oct · 2 days left
M3 Backend v2 on dev project 0 of 20 · due 30 Oct · 4 days left
M4 Customer app, Android + iOS 0 of 50 · due 2 Nov · 7 days left
M5 Kitchen + rider apps 0 of 16 · due 5 Nov · 10 days left
M6 Admin + launch hardening 0 of 11 · due 8 Nov · 13 days left

What waits for what

MVP0 demo 18 OctMVP 1 Golden pathMVP 2 Pilot readyMVP 2.5 Pilot hardeningM0 Roadmap liveM1 MVP2 demo-ready (PWA, frozeM2 Design v2 approvedM3 Backend v2 on dev projectM4 Customer app, Android + iOSM5 Kitchen + rider appsM6 Admin + launch hardening3 needs4 needs1 need2 needs36 needs4 needs16 needs

Arrow: the later box waits for the earlier box. Dotted: it waits for a later milestone. 2 crossings. 5 arrows that only repeat a longer path are left out.

Longest chain of open work (17): #316 → #317 → #319 → #337 → #338 → #343 → #344 → #345 → #347 → #349 → #350 → #352 → #374 → #380 → #382 → #433 → #434

Timeline

26 Oct

25 Oct

22 Oct

14 Oct

13 Oct

Now

Next

Older open work

26 stories from before the plan
  • Story: UptimeRobot monitors for dev and prod #55
  • Story: S-C2 Web Push for the delivered prompt (after the demo) #96
  • Story: S-E UAT numbers in the 21:00 card and Ops panel (after the demo) #97
  • Story: Laya training data generator and validator #107
  • Story: Laya train and eval scripts on Kaggle (E2) #111
  • Story: Laya data v2 (large, realistic) and retrain to targets (E3) #113
  • Story: S-M4 Jev D2 ETA (23 Oct) #120
  • Story: Laya round 3, code for refund and at_risk, train-only seeds, at most 2 retrains #127
  • Story: Laya robustness check, new data kind with order context, fresh held-out test, continue training #131
  • Story: Laya round 5, blind test, pressure suite, one data round, one retrain #137
  • Kitchen, rider and admin screens look and feel like one product. #155
  • Prod runs the whole system. #156
  • One table of rules, the database is the truth, the app mirrors it, one test per rule (`docs/product/validation-rules.md`). #187
  • Addresses become points; orders outside the kitchen's radius or at unknown addresses are refused; ETA uses real km. #191
  • The menu and tracker built four times with four design skills; the owner picks one blind. #192
  • A table of integrations with tiers, costs and when. #196
  • Story: H17 PostHog product analytics #207
  • A stranger who opens the repo reads in two minutes what GoServe is, what already works for a customer, a cook, a rider and the admin, how it runs, and where the plan is. #246
  • Anyone with the link sees where GoServe is, live, from any phone; the roadmap stops being a file on one Mac. #247
  • A rider's phone in the pocket still tells the kitchen and the customer where the food is. #252
  • A tester installs GoServe from the Play Store in one tap, no sideloading warnings. #254
  • On Sunday 2 November the owner installs the APK and does one full day of GoServe on his phone: order, cook, ride, run the city, with nothing missing. #255
  • The customer sees where the food really is: each kitchen stage with its time, an arrival range that is updated before it slips, the reason for any delay, and the rider on a live map after pickup. #266
  • Laya and Jev answer beside the rules on real orders without deciding anything, and a daily line shows whether either would have beaten the rules. #267
  • Travel times come from real roads, not straight lines, so the arrival range is right near flyovers, the Yamuna and one-way lanes. #268
  • At thousands of riders and kitchens, a dedicated matcher runs every 10 to 30 seconds per city part and keeps idle riders where the next orders will come. #269

Board

To do 143

Monitoring and demo readiness

Story: UptimeRobot monitors for dev and prod

#55
UAT v2 (feedback, delivered by hand, UAT numbers)

Story: S-C2 Web Push for the delivered prompt (after the demo)

#96
UAT v2 (feedback, delivered by hand, UAT numbers)

Story: S-E UAT numbers in the 21:00 card and Ops panel (after the demo)

#97
Fine-tune Laya on GoServe decisions (Kaggle GPU)

Story: Laya training data generator and validator

#107
Fine-tune Laya on GoServe decisions (Kaggle GPU)

Story: Laya train and eval scripts on Kaggle (E2)

#111
Fine-tune Laya on GoServe decisions (Kaggle GPU)

Story: Laya data v2 (large, realistic) and retrain to targets (E3)

#113
MVP 1 Golden path

Story: S-M4 Jev D2 ETA (23 Oct)

#120
Fine-tune Laya on GoServe decisions (Kaggle GPU)

Story: Laya round 3, code for refund and at_risk, train-only seeds, at most 2 retrains

#127
Fine-tune Laya on GoServe decisions (Kaggle GPU)

Story: Laya robustness check, new data kind with order context, fresh held-out test, continue training

#131
Fine-tune Laya on GoServe decisions (Kaggle GPU)

Story: Laya round 5, blind test, pressure suite, one data round, one retrain

#137
Design system and investor-grade UI

Kitchen, rider and admin screens look and feel like one product.

#155
Release MVP 2 and closure

Prod runs the whole system.

#156
Pilot blockers and validation rules

One table of rules, the database is the truth, the app mirrors it, one test per rule (`docs/product/validation-rules.md`).

#187
Maps

Addresses become points; orders outside the kitchen's radius or at unknown addresses are refused; ETA uses real km.

#191
UI pass 2

The menu and tracker built four times with four design skills; the owner picks one blind.

#192
Integrations map

A table of integrations with tiers, costs and when.

#196
Pilot reporting, platform health, README, analytics

Story: H17 PostHog product analytics

#207
Pilot reporting, platform health, README, analytics

A stranger who opens the repo reads in two minutes what GoServe is, what already works for a customer, a cook, a rider and the admin, how it runs, and where the plan is.

#246
Live roadmap page

Anyone with the link sees where GoServe is, live, from any phone; the roadmap stops being a file on one Mac.

#247
MVP 3, Android APK by 2 Nov 2026, zero running cost

A rider's phone in the pocket still tells the kitchen and the customer where the food is.

#252
MVP 3, Android APK by 2 Nov 2026, zero running cost

A tester installs GoServe from the Play Store in one tap, no sideloading warnings.

#254
MVP 3, Android APK by 2 Nov 2026, zero running cost

On Sunday 2 November the owner installs the APK and does one full day of GoServe on his phone: order, cook, ride, run the city, with nothing missing.

#255
Dispatch and live tracking, from one kitchen to thousands

The customer sees where the food really is: each kitchen stage with its time, an arrival range that is updated before it slips, the reason for any delay, and the rider on a live map after pickup.

#266
Dispatch and live tracking, from one kitchen to thousands

Laya and Jev answer beside the rules on real orders without deciding anything, and a daily line shows whether either would have beaten the rules.

#267
Dispatch and live tracking, from one kitchen to thousands

Travel times come from real roads, not straight lines, so the arrival range is right near flyovers, the Yamuna and one-way lanes.

#268
Dispatch and live tracking, from one kitchen to thousands

At thousands of riders and kitchens, a dedicated matcher runs every 10 to 30 seconds per city part and keeps idle riders where the next orders will come.

#269
Roadmap and process

Everyone can see which branch holds what, and every story has the labels it needs.

#316
Roadmap and process

The whole plan is one list of small stories that anyone can read and pick from.

#317
Roadmap and process

Anyone with a link sees where GoServe is today, what is next, and what waits on what, on a phone.

#319
MVP2 demo freeze (PWA)

The founder's iPhone always shows the newest version of the app.

#320
MVP2 demo freeze (PWA)

A customer cannot order from a kitchen that is closed.

#321
MVP2 demo freeze (PWA)

A customer on a pin code we do not serve is told so kindly.

#322
MVP2 demo freeze (PWA)

The founder can show GoServe in ten steps and know what to say.

#323
MVP2 demo freeze (PWA)

The demo has been run twice before the founder shows it.

#324
MVP2 demo freeze (PWA)

The owner has tried every feature on his own phone.

#325
MVP2 demo freeze (PWA)

The demo version is safe and stays as it is.

#326
Design v2 (the Living Slip)

Our design starts from what Apple has learned about clear apps.

#327
Design v2 (the Living Slip)

The Android app follows its own platform's rules and matches iOS.

#328
Design v2 (the Living Slip)

We learn from good open examples and know how far to trust each source.

#329
Design v2 (the Living Slip)

We know exactly what a good quick-food app does at each step.

#330
Design v2 (the Living Slip)

The team shares seven simple rules and one big idea for the look of the app.

#331
Design v2 (the Living Slip)

Both apps get the same colours, type and spacing from one file.

#332
Design v2 (the Living Slip)

The owner can see the customer app before it is built.

#333
Design v2 (the Living Slip)

The owner can see the staff apps before they are built.

#334
Design v2 (the Living Slip)

Every screen has been asked five hard questions.

#335
Design v2 (the Living Slip)

The owner agrees to the look before any app is built.

#336
Backend v2

The new server has a home that deploys by itself.

#337
Backend v2

The apps and the server agree on every field in one file.

#338
Backend v2

A customer signs in with their phone number and a code.

#339
Backend v2

A customer can keep their name and email and can delete their data.

#340
Backend v2

A customer saves addresses and picks one in a tap.

#341
Backend v2

The app knows whether a kitchen can deliver to a place, and how soon.

#342
Backend v2

The menu shows badges, tags and collections like a modern food app.

#343
Backend v2

A dish can have choices, like spice level or extras, with limits.

#344
Backend v2

The bill is computed in one place, so every app shows the same price.

#345
Backend v2

The best offer is chosen for the customer by the server.

#346
Backend v2

An order is placed once, with the price the customer saw.

#347
Backend v2

A customer can pay by UPI or card, and cash on delivery still works.

#348
Backend v2

Kitchens and riders move an order along through the new server.

#349
Backend v2

A rider is chosen by the new server when food is ready.

#350
Backend v2

Phones are told when something changes.

#351
Backend v2

A customer sees the order and the rider move.

#352
Backend v2

A late order gives the customer a coupon by itself.

#353
Backend v2

A customer rates the food and the rider.

#354
Backend v2

A customer finds answers without calling us.

#355
Backend v2

Every call leaves a row, so problems can be found.

#356
Android app (Kotlin)

Every change to the app is built and tested by itself.

#357
Android app (Kotlin)

One app opens for customer, kitchen, rider and admin.

#358
Android app (Kotlin)

The app looks like our design because the theme comes from one file.

#359
Android app (Kotlin)

The app talks to the server with code made from the contract.

#360
Android app (Kotlin)

Testers install the app from the store in one tap.

#361
Android app (Kotlin)

A new customer sees what the app does in three slides.

#362
Android app (Kotlin)

A customer signs in with a phone number and a code.

#363
Android app (Kotlin)

A customer says where to deliver by pin on a map.

#364
Android app (Kotlin)

A customer adds house details once and reuses them.

#365
Android app (Kotlin)

A customer outside our area is told kindly and can ask us to come.

#366
Android app (Kotlin)

A customer sees an honest ETA and the food at once.

#367
Android app (Kotlin)

A customer browses one kind of food.

#368
Android app (Kotlin)

A customer sees what a dish is and whether it is available.

#369
Android app (Kotlin)

A customer picks the choices of a dish.

#370
Android app (Kotlin)

A customer always sees what is in the cart.

#371
Android app (Kotlin)

A customer sees the whole bill as one slip, with the savings.

#372
Android app (Kotlin)

A customer pays by UPI, card or cash.

#373
Android app (Kotlin)

A customer watches the order become a delivery.

#374
Android app (Kotlin)

The order shows on the lock screen.

#375
Android app (Kotlin)

A customer finds past orders and orders again in one tap.

#376
Android app (Kotlin)

A customer rates after delivery.

#377
Android app (Kotlin)

A customer manages their profile and gets help.

#379
Android app (Kotlin)

A customer hears when the order changes.

#380
Android app (Kotlin)

The app never shows a blank page.

#381
Android app (Kotlin)

People with different needs can use the app.

#382
Android app (Kotlin)

Kitchen staff sign in with Google and pick their kitchen.

#383
Android app (Kotlin)

The kitchen hears a new order and accepts it.

#384
Android app (Kotlin)

The cook sees exactly what to make.

#385
Android app (Kotlin)

The kitchen controls what customers can order.

#386
Android app (Kotlin)

A rider signs in and goes on duty.

#387
Android app (Kotlin)

A rider walks through pickup to delivered, with cash or prepaid.

#388
Android app (Kotlin)

The customer sees the rider move even when the rider's screen is off.

#389
Android app (Kotlin)

A rider sees their day.

#390
Android app (Kotlin)

The admin sees every order and can cancel one.

#391
Android app (Kotlin)

The admin runs the city.

#392
Android app (Kotlin)

The admin changes menus, add-ons and offers.

#393
Android app (Kotlin)

The admin sees the numbers and the demo city.

#394
iOS app (Swift)

Every change to the app is built and tested by itself.

#395
iOS app (Swift)

One app opens for customer, kitchen, rider and admin.

#396
iOS app (Swift)

The app looks like our design because the theme comes from one file.

#397
iOS app (Swift)

The app talks to the server with code made from the contract.

#398
iOS app (Swift)

Testers install the app from the store in one tap.

#399
iOS app (Swift)

A new customer sees what the app does in three slides.

#400
iOS app (Swift)

A customer signs in with a phone number and a code.

#401
iOS app (Swift)

A customer says where to deliver by pin on a map.

#402
iOS app (Swift)

A customer adds house details once and reuses them.

#403
iOS app (Swift)

A customer outside our area is told kindly and can ask us to come.

#404
iOS app (Swift)

A customer sees an honest ETA and the food at once.

#405
iOS app (Swift)

A customer browses one kind of food.

#406
iOS app (Swift)

A customer sees what a dish is and whether it is available.

#407
iOS app (Swift)

A customer picks the choices of a dish.

#408
iOS app (Swift)

A customer always sees what is in the cart.

#409
iOS app (Swift)

A customer sees the whole bill as one slip, with the savings.

#410
iOS app (Swift)

A customer pays by UPI, card or cash.

#411
iOS app (Swift)

A customer watches the order become a delivery.

#412
iOS app (Swift)

The order shows on the lock screen.

#413
iOS app (Swift)

A customer finds past orders and orders again in one tap.

#414
iOS app (Swift)

A customer rates after delivery.

#415
iOS app (Swift)

A customer manages their profile and gets help.

#416
iOS app (Swift)

A customer hears when the order changes.

#417
iOS app (Swift)

The app never shows a blank page.

#418
iOS app (Swift)

People with different needs can use the app.

#419
iOS app (Swift)

Kitchen staff sign in with Google and pick their kitchen.

#420
iOS app (Swift)

The kitchen hears a new order and accepts it.

#421
iOS app (Swift)

The cook sees exactly what to make.

#422
iOS app (Swift)

The kitchen controls what customers can order.

#423
iOS app (Swift)

A rider signs in and goes on duty.

#424
iOS app (Swift)

A rider walks through pickup to delivered, with cash or prepaid.

#425
iOS app (Swift)

The customer sees the rider move even when the rider's screen is off.

#426
iOS app (Swift)

A rider sees their day.

#427
iOS app (Swift)

The admin sees every order and can cancel one.

#428
iOS app (Swift)

The admin runs the city.

#429
iOS app (Swift)

The admin changes menus, add-ons and offers.

#430
iOS app (Swift)

The admin sees the numbers and the demo city.

#431
Launch v2

People can find and trust the app in the stores.

#432
Launch v2

The owner has tried everything on both phones.

#433
Launch v2

Version 2 is released.

#434

Doing 0

Review 0

Done 77

investor doorway site (letsdwelo.in)

Story: capture pre-registration and investor leads from the site

#5
architecture evolution and procurement plan

Story: architecture evolution page, components per phase, and Laya plan

#16
investor doorway site (letsdwelo.in)

Story: Delhi as first city on the site, and a home for design tokens

#18
architecture evolution and procurement plan

Story: MVP 0 readiness, components refresh, options research

#20
architecture evolution and procurement plan

Story: deep ops research, MVP 0 setup decisions, phase gate

#22
App foundation and build and deploy

Story: Scaffold the app (React, Vite, TypeScript, PWA, tokens)

#39
App foundation and build and deploy

Story: CI job for app/ and the pre-commit hooks

#40
App foundation and build and deploy

Story: Dev deploy: push to dev publishes to Vercel goserve-app-dev

#41
App foundation and build and deploy

Story: Prod deploy: main publishes to Cloudflare Pages goserve-app

#42
Data layer (Supabase)

Story: Schema: 7 tables and the legal-status rule

#43
Data layer (Supabase)

Story: Row level security, Realtime and the Delhi sample menu

#44
Order API (n8n GS workflows)

Story: Place order and change status workflows (MAIN 01, SUB 11, SUB 12)

#45
Order API (n8n GS workflows)

Story: Decide and logs workflows (SUB 13, SUB 14)

#46
Order API (n8n GS workflows)

Story: Daily scorecard workflow (MAIN 90)

#47
Screens (customer, kitchen, rider, ops)

Story: Customer screen: menu, cart, bill, place order

#48
Screens (customer, kitchen, rider, ops)

Story: Kitchen screen: live orders with Accept, Start, Ready

#49
Screens (customer, kitchen, rider, ops)

Story: Rider steps and live customer status through Delivered

#50
Screens (customer, kitchen, rider, ops)

Story: Ops screen: AI suggestion and metrics panel

#51
Demo safety net

Story: Split view, own space per session and reset

#52
Demo safety net

Story: Autopilot that works in airplane mode

#53
Demo safety net

Story: Health check page (Supabase, n8n, Jev)

#54
Monitoring and demo readiness

Story: 20 of 20 scripted runs, founder Android check and backup video

#56
Monitoring and demo readiness

Story: Production release prep (prod database, app, workflows)

#78
Screens (customer, kitchen, rider, ops)

Story: Role apps (customer, kitchen, rider, ops) as separate installable PWAs, one device first

#83
UAT v2 (feedback, delivered by hand, UAT numbers)

Story: S-B Feedback button inside the app

#94
UAT v2 (feedback, delivered by hand, UAT numbers)

Story: S-C Delivered by hand, paid by cash

#95
MVP 1 Golden path

Story: S-M1 Google login linked to the anonymous user

#117
MVP 1 Golden path

Story: S-M2 No order lost or doubled, proven

#118
MVP 1 Golden path

Story: S-M3 MVP 1 gate, closure and release

#119
MVP 1 Golden path

Story: S-M5 Privacy and Terms pages for the Google consent screen

#123
MVP 1 Golden path

Story: S-M5 Kitchen account

#132
MVP 1 Golden path

Story: S-M6 Rider account

#135
City data model

Everything else needs one data model that holds many kitchens, customers, riders and admins.

#148
Admin panel

The founder adds a kitchen and its people without touching the database.

#149
Admin panel

Each kitchen's menu is managed by the founder, with real photos.

#150
Admin panel

The founder sees the day and can stop a bad order.

#151
Dispatch and riders

Each order goes to one rider, chosen by rule, and the rider sees only their own orders.

#152
Kitchen operations

A kitchen controls what a customer can order right now.

#153
Notifications

The customer learns about the order without keeping the app open.

#154
Customer flows (functional)

A refresh must not lose the customer's place.

#157
Customer flows (functional)

A customer orders from a kitchen that serves their area.

#158
Customer flows (functional)

The customer has an account-like experience on a cash order.

#159
Design system and investor-grade UI

One set of components and tokens for every screen.

#160
Design system and investor-grade UI

The customer app passes the benchmark table.

#161
Pilot blockers and validation rules

A kitchen cannot be saved or kept active without a pin code, a valid phone, sane hours or a unique name; a dish needs a price above zero and a unique name.

#184
Pilot blockers and validation rules

The demo console at `/` and the other role apps cannot place orders or read menus on prod.

#185
Pilot blockers and validation rules

A staff user belongs to one kitchen, and the kitchen app says so loudly when the account is not staff.

#186
Synthetic city on prod

One n8n API seeds synthetic kitchens, riders and dishes from parameters and one resets them.

#188
Synthetic city on prod

A scheduled tick moves synthetic riders and flips synthetic kitchens and dishes while the simulator is on.

#189
Synthetic city on prod

The admin sets parameters, seeds, resets and switches the tick on and off, and sees counts.

#190
UI pass 2

The winning skill applied to every customer screen.

#193
UI pass 2

The winning skill applied to the rider and kitchen apps, one-thumb.

#194
UI pass 2

The winning skill applied to admin tables and forms.

#195
UI pass 2

letsdwelo.in shows three pages in the Ink v3 look: Home, For investors, Pre-register.

#200
Pilot reporting, platform health, README, analytics

Story: H14 Pilot report and watch

#204
Pilot reporting, platform health, README, analytics

Story: H15 Platform health and cost

#205
Pilot reporting, platform health, README, analytics

Story: H16 README v2 for tech investors

#206
UI pass 2

A customer never signs in.

#224
UI pass 2

The app opens in Day for everyone until the owner says otherwise.

#225
Pilot reporting, platform health, README, analytics

The rider's cash in hand and the kitchen's slips must add up at the end of the day, and a delivery at 23:30 must not vanish from the rider's day at midnight.

#229
Pilot reporting, platform health, README, analytics

A cook who already started a dish must know the order was cancelled, not just see it vanish.

#230
Pilot reporting, platform health, README, analytics

The cook wants to know who is coming for a ready order, not just that someone is.

#231
Live roadmap page

Open one page and know where GoServe is: what customers, kitchens and riders already have, what is being built this week, what comes next, and every ticket on a board.

#239
Pilot reporting, platform health, README, analytics

Every app shows only its board.

#242
MVP 3, Android APK by 2 Nov 2026, zero running cost

Before we build, we know the APK is real: one role installs and runs on the owner's phone, and we know what works and what does not.

#250
MVP 3, Android APK by 2 Nov 2026, zero running cost

Anyone can download the latest GoServe app from one page and install it.

#251
MVP 3, Android APK by 2 Nov 2026, zero running cost

Nothing paid runs when nobody asked for it.

#253
MVP 3, Android APK by 2 Nov 2026, zero running cost

The admin picks who makes the live decisions: Rules, Jev or Laya.

#263
Dispatch and live tracking, from one kitchen to thousands

When an order is ready, the nearest free rider gets it, so the food waits less and reaches the door sooner.

#272
Pilot reporting, platform health, README, analytics

The menu looks right again: photo on the left, name and price in the middle, Add on the right, open or closed.

#274
Synthetic city on prod

When someone opens GoServe in Delhi, they see ten kitchens worth ordering from, the kinds we want to sign, each with a full menu at today's prices.

#282
Synthetic city on prod

A customer on a real Delhi pin sees the demo kitchens and gets a rider, for every kitchen, the two old ones too.

#283
Synthetic city on prod

An order on a demo kitchen moves like a real one: accepted, cooked, picked up and delivered by a moving rider.

#284
Synthetic city on prod

A customer in East Delhi (pin 110092, the owner's own pin) has a kitchen close by, not one 8 to 10 km away.

#290
Synthetic city on prod

When someone opens a demo kitchen's menu, every dish shows a real, good-looking photo.

#292
MVP 3, Android APK by 2 Nov 2026, zero running cost

Google Play asks for a privacy page before it lets testers install.

#302
Roadmap and process

Each goal has a date and a check that anyone can measure.

#318