GoServe roadmap

updated 20:57 · 153 of 277 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) 4 done · 11 Oct to 13 Oct

  • Every lead from the investor site is saved and sent to us at once, so no lead is lost.
  • The lead alert on Telegram and the saved lead show every field, not blanks.
  • Every lead alert comes from our own bot, GoServeBot.
  • Delhi is the first city on the site, and every colour and font has one home.
architecture evolution and procurement plan 5 done · 11 Oct to 13 Oct

  • There is one place for every learning and mistake, and the process uses it.
  • There is one list of every part of the system, by phase.
  • Investors can see how GoServe grows from a demo to a city, one page, one phase at a time.
  • Before the first build, every missing part is known, and the options for each are written down.
  • Before every MVP phase there is a gate: we stop and check that the setup is ready.
App foundation and build and deploy 4 done · 14 Oct to 14 Oct

The app has a home, its checks, and its two deploy paths.

  • The app exists, installs on a phone, and uses the brand's colours from one file.
  • Every change to the app is checked by a machine before anyone can merge it.
  • Every push to the dev branch gives the owner a live dev site to look at.
  • A release to main puts the app on its public address by itself.
Data layer (Supabase) 2 done · 14 Oct to 14 Oct

The database holds the order and refuses illegal steps.

  • The database has the seven tables the order needs, and refuses an illegal order step.
  • Each person sees only their own data, the kitchen sees new orders live, and Delhi has a sample menu.
Order API (n8n GS workflows) 3 done · 14 Oct to 14 Oct

The workflows place orders, change status, decide and log.

  • An order can be placed and moved through its steps by the workflows, with every step logged.
  • The system suggests a decision on each order and keeps a log of what it decided.
  • The owner gets a daily scorecard on Telegram without asking.
Screens (customer, kitchen, rider, ops) 5 done · 14 Oct to 22 Oct

Customer, kitchen, rider and ops each have a screen in one app.

  • A customer can open the menu, fill a cart, see the bill and place an order.
  • The kitchen sees live orders and moves each one with Accept, Start and Ready.
  • The rider walks the delivery steps, and the customer sees the status up to Delivered.
  • The founder sees the system's suggestion and the day's numbers on one ops screen.
  • Customer, kitchen, rider and ops each get their own installable app, from one codebase.
Demo safety net 3 done · 14 Oct to 14 Oct

The pitch cannot fail: autopilot, split view, reset and a health page.

  • The demo shows all four roles side by side, each in its own space, with a reset.
  • The demo plays by itself even with no internet.
  • One page shows whether Supabase, n8n and Jev are up, before a demo.
Monitoring and demo readiness 3 done · 22 Oct to 25 Oct

Monitors watch the app, and the demo was rehearsed and recorded.

  • A monitor watches dev and prod and tells us when the app is down.
  • The demo ran 20 times out of 20, on the founder's Android phone, with a backup video.
  • Production is ready: its own database, app address and workflows, before the first real demo.
UAT v2 (feedback, delivered by hand, UAT numbers) 4 done · 22 Oct to 22 Oct

Testers can install the app, report problems, and deliver by hand.

  • A tester sees something odd and tells us in ten seconds, without leaving the app and without WhatsApp.
  • Nobody delivers in the UAT.
  • A tester places an order, puts the phone in the pocket, and three minutes after the kitchen taps Ready the phone buzzes: "Was your order delivered?
  • After each UAT day the owner sees, in the 21:00 Telegram card and on the Ops screen: how many reports came in, how many orders customers confirmed, how often Jev answered in time, what it cost, and how many refusals (409, 503) happened.
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.
Roadmap and process 5 done · 26 Oct to 27 Oct

Everyone can see the plan, the order of work, who waits on what, and how long each story took.

  • Everyone can see which branch holds what, and every story has the labels it needs.
  • The whole plan is one list of small stories that anyone can read and pick from.
  • Each goal has a date and a check that anyone can measure.
  • Anyone with a link sees where GoServe is today, what is next, and what waits on what, on a phone.
  • Every closed story shows its cycle time on the roadmap, even the 92 that closed before the `doing` label existed.

You are here

27 Oct 20:57 India time

Next to start: The demo has been run twice before the founder shows it. #324

Milestones

MVP0 demo 18 Oct 30 of 30 · due 18 Oct · finished after its date
MVP 1 Golden path 6 of 9 · due 22 Oct · late by 5 days
MVP 2 Pilot ready 12 of 22 · due 24 Oct · late by 3 days
MVP 2.5 Pilot hardening 27 of 34 · due 26 Oct · late by 1 day
M0 Roadmap live 6 of 7 · due 26 Oct · late by 1 day
M1 MVP2 demo-ready (PWA, frozen) 23 of 27 · due 27 Oct · due today
M2 Design v2 approved 8 of 16 · due 28 Oct · 1 day left
M3 Backend v2 on dev project 35 of 39 · due 30 Oct · 3 days left
M4 Customer app, Android + iOS 5 of 58 · due 2 Nov · 6 days left
M5 Kitchen + rider apps 0 of 18 · due 5 Nov · 9 days left
M6 Admin + launch hardening 0 of 11 · due 8 Nov · 12 days left
MVP 3 Intelligence 1 of 6 · due 2 Dec · 36 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 hardeningMVP 3 Intelligence3 needs4 needs1 need2 needs36 needs2 needs4 needs16 needs

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

Longest chain of open work (12): #331 → #332 → #359 → #367 → #371 → #372 → #373 → #374 → #380 → #382 → #433 → #434

Timeline

27 Oct

26 Oct

25 Oct

22 Oct

14 Oct

13 Oct

11 Oct

Now

Next

Older open work

33 stories from before the plan
  • A monitor watches dev and prod and tells us when the app is down. #55
  • A tester places an order, puts the phone in the pocket, and three minutes after the kitchen taps Ready the phone buzzes: "Was your order delivered? #96
  • After each UAT day the owner sees, in the 21:00 Telegram card and on the Ops screen: how many reports came in, how many orders customers confirmed, how often Jev answered in time, what it cost, and how many refusals (409, 503) happened. #97
  • We can make realistic practice data for Laya and check it before training. #107
  • Laya can be trained on a free Kaggle GPU and compared with the base model. #111
  • Laya is trained on much larger data until every decision meets its target. #113
  • Jev gives a delivery time estimate for each order. #120
  • Laya learns refund and at-risk decisions from code, with at most two retrains. #127
  • Laya is checked on new, bigger data with order context, to see if its results hold. #131
  • Laya passes a blind test and a pressure test before it is trusted. #137
  • Google's consent screen shows the GoServe name and logo. #139
  • 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
  • We can see what people do in the app with 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
  • Someone who opens the bare `goserve-app.pages.dev` should understand GoServe in one scroll, like justswish.in, and reach the right door: customer, kitchen, rider or admin. #503
  • The first screen should give before it asks: one tap finds where you are, and you see your kitchen and today's food before the menu. #508
  • When people get hungry at their own odd hours, GoServe sends one interesting push that names the perfect dish for that moment. #517
  • A push that was taken from the queue but never sent must not be lost. #534
  • A customer who got a "Sorry we were late" coupon can see it in their offers and use it. #579
  • The demo is rehearsed on the real app before the founder shows it, and each run leaves a record. #584

Board

To do 122

Monitoring and demo readiness

A monitor watches dev and prod and tells us when the app is down.

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

A tester places an order, puts the phone in the pocket, and three minutes after the kitchen taps Ready the phone buzzes: "Was your order delivered?

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

After each UAT day the owner sees, in the 21:00 Telegram card and on the Ops screen: how many reports came in, how many orders customers confirmed, how often Jev answered in time, what it cost, and how many refusals (409, 503) happened.

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

We can make realistic practice data for Laya and check it before training.

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

Laya can be trained on a free Kaggle GPU and compared with the base model.

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

Laya is trained on much larger data until every decision meets its target.

#113
MVP 1 Golden path

Jev gives a delivery time estimate for each order.

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

Laya learns refund and at-risk decisions from code, with at most two retrains.

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

Laya is checked on new, bigger data with order context, to see if its results hold.

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

Laya passes a blind test and a pressure test before it is trusted.

#137
Pilot blockers and validation rules

Google's consent screen shows the GoServe name and logo.

#139
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

We can see what people do in the app with 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
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)

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 best offer is chosen for the customer by the server.

#346
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
Android app (Kotlin)

A person who works in two kitchens picks which one they are serving, and can switch without signing out.

#469
iOS app (Swift)

A person who works in two kitchens picks which one they are serving, and can switch without signing out.

#470
Design v2 (the Living Slip)

Someone who opens the bare `goserve-app.pages.dev` should understand GoServe in one scroll, like justswish.in, and reach the right door: customer, kitchen, rider or admin.

#503
Design v2 (the Living Slip)

The first screen should give before it asks: one tap finds where you are, and you see your kitchen and today's food before the menu.

#508
Launch v2

When people get hungry at their own odd hours, GoServe sends one interesting push that names the perfect dish for that moment.

#517
MVP2 demo freeze (PWA)

A push that was taken from the queue but never sent must not be lost.

#534
Backend v2

The order total means one thing everywhere, so the kitchen, the rider, the numbers and the bill always agree.

#538
no epic

A customer who got a "Sorry we were late" coupon can see it in their offers and use it.

#579
no epic

The demo is rehearsed on the real app before the founder shows it, and each run leaves a record.

#584

Doing 1

Backend v2

A customer finds answers without calling us.

#355 · PR #582

Review 1

MVP2 demo freeze (PWA)

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

#324 · PR #583

Done 153

investor doorway site (letsdwelo.in)

Every lead from the investor site is saved and sent to us at once, so no lead is lost.

#5
investor doorway site (letsdwelo.in)

The lead alert on Telegram and the saved lead show every field, not blanks.

#6
investor doorway site (letsdwelo.in)

Every lead alert comes from our own bot, GoServeBot.

#8
architecture evolution and procurement plan

There is one place for every learning and mistake, and the process uses it.

#10
architecture evolution and procurement plan

There is one list of every part of the system, by phase.

#13
architecture evolution and procurement plan

Investors can see how GoServe grows from a demo to a city, one page, one phase at a time.

#16
investor doorway site (letsdwelo.in)

Delhi is the first city on the site, and every colour and font has one home.

#18
architecture evolution and procurement plan

Before the first build, every missing part is known, and the options for each are written down.

#20
architecture evolution and procurement plan

Before every MVP phase there is a gate: we stop and check that the setup is ready.

#22
App foundation and build and deploy

The app exists, installs on a phone, and uses the brand's colours from one file.

#39
App foundation and build and deploy

Every change to the app is checked by a machine before anyone can merge it.

#40
App foundation and build and deploy

Every push to the dev branch gives the owner a live dev site to look at.

#41
App foundation and build and deploy

A release to main puts the app on its public address by itself.

#42
Data layer (Supabase)

The database has the seven tables the order needs, and refuses an illegal order step.

#43
Data layer (Supabase)

Each person sees only their own data, the kitchen sees new orders live, and Delhi has a sample menu.

#44
Order API (n8n GS workflows)

An order can be placed and moved through its steps by the workflows, with every step logged.

#45
Order API (n8n GS workflows)

The system suggests a decision on each order and keeps a log of what it decided.

#46
Order API (n8n GS workflows)

The owner gets a daily scorecard on Telegram without asking.

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

A customer can open the menu, fill a cart, see the bill and place an order.

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

The kitchen sees live orders and moves each one with Accept, Start and Ready.

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

The rider walks the delivery steps, and the customer sees the status up to Delivered.

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

The founder sees the system's suggestion and the day's numbers on one ops screen.

#51
Demo safety net

The demo shows all four roles side by side, each in its own space, with a reset.

#52
Demo safety net

The demo plays by itself even with no internet.

#53
Demo safety net

One page shows whether Supabase, n8n and Jev are up, before a demo.

#54
Monitoring and demo readiness

The demo ran 20 times out of 20, on the founder's Android phone, with a backup video.

#56
Monitoring and demo readiness

Production is ready: its own database, app address and workflows, before the first real demo.

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

Customer, kitchen, rider and ops each get their own installable app, from one codebase.

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

A tester sees something odd and tells us in ten seconds, without leaving the app and without WhatsApp.

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

Nobody delivers in the UAT.

#95
MVP 1 Golden path

A customer can sign in with Google and keep the orders they placed before signing in.

#117
MVP 1 Golden path

No order is lost or doubled, even when the network drops, and we proved it.

#118
MVP 1 Golden path

MVP 1 is closed with a gate log, a closure note and a release.

#119
MVP 1 Golden path

The app has privacy and terms pages, so Google sign-in can show them.

#123
MVP 1 Golden path

A kitchen worker signs in with Google and sees their own kitchen.

#132
MVP 1 Golden path

A rider signs in with Google and sees their own deliveries.

#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

The owner gets a pilot report and a watch on the pilot's numbers.

#204
Pilot reporting, platform health, README, analytics

The owner sees the platform's health and what it costs.

#205
Pilot reporting, platform health, README, analytics

A tech investor can read what GoServe is built of in one README.

#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

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

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

#318
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
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
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

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

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

#356
MVP2 demo freeze (PWA)

A customer who sees a kitchen closed in the middle of the day is told the truth, not that it opens tomorrow morning.

#452
MVP2 demo freeze (PWA)

The founder turns on one "demo mode" switch before a demo.

#454
MVP2 demo freeze (PWA)

A customer is never asked "Was your order delivered?" while the kitchen is still cooking.

#456
MVP2 demo freeze (PWA)

The Simulator tab looks as well made as the rest of the admin, so the founder is not embarrassed when he shows it.

#461
MVP2 demo freeze (PWA)

When the admin does something that cannot be done, the screen says why in words he can read.

#466
Backend v2

One person can run more than one kitchen: owner of one, staff in another, with one sign-in.

#468
MVP2 demo freeze (PWA)

The owner's decision rules are written down in plain words, so the reviewer can decide as he would and the owner can correct them; and GoServe uses ShipQuick v0.6.1.

#477
MVP2 demo freeze (PWA)

Nothing the customer must tap hides under the iPhone home bar or the status bar.

#481
MVP2 demo freeze (PWA)

The customer must know when the food comes, with the app closed.

#483
MVP2 demo freeze (PWA)

When something goes wrong on a phone, we must see what happened to that order, in order, from real logs.

#484
MVP2 demo freeze (PWA)

One way to do a thing, never two (owner rule, 27 Oct).

#485
MVP2 demo freeze (PWA)

The owner must know every day whether the prod database is healthy and how far it is from each Supabase free limit, and get an alert before a limit is hit.

#488
MVP2 demo freeze (PWA)

The decisions, rules and research of 27 Oct must be written down so any session can find them.

#489
MVP2 demo freeze (PWA)

The release, the daily limits card and the n8n publish rule must be written down so any session can find them.

#495
MVP2 demo freeze (PWA)

There is one roadmap.

#497
MVP2 demo freeze (PWA)

The customer must hear when the rider picks up the food.

#500
MVP2 demo freeze (PWA)

The app must never ask "Was your order delivered?" for an order that is already delivered, and a notice must not repeat what the server push already says.

#501
Design v2 (the Living Slip)

The owner's Night lamp idea and the motion framework must be kept in the repo, and today's records written down.

#506
Design v2 (the Living Slip)

The owner's own Swish screen is the best source we have.

#509
Design v2 (the Living Slip)

The owner's round-2 motion feedback must not be lost.

#511
Design v2 (the Living Slip)

A reviewer mistake the owner corrected must teach the next session: the light zigzag colour is deliberate.

#513
Roadmap and process

Every closed story shows its cycle time on the roadmap, even the 92 that closed before the `doing` label existed.

#518
UI pass 2

The pin mark in the Menu header stays where it is when you switch tabs; it flies in only once, right after you pick your pin code.

#525
UI pass 2

The app says "Good morning!" to a stranger, and "Good morning, Priya." only once it knows her name.

#527
UI pass 2

On the thali toggle, the veg and non-veg marks stay readable, and the chosen side is still clear.

#528
MVP2 demo freeze (PWA)

A slow database moment must not skip a push round.

#532
Backend v2

A customer who taps Place order twice, or whose phone retries after a drop, gets the order they already made, not an error.

#537
MVP2 demo freeze (PWA)

A slow database moment must not skip a tick of the simulator, the dispatcher, the push drain or the daily numbers.

#541
no epic

When the owner is ready, each service takes him one click.

#544
no epic

Everything the coder did and learned on 27 Oct is written down, so the next session finds it and repeats no mistake.

#545
no epic

A customer can sign in with a phone number and a code at checkout; the screens exist now, the real SMS plugs in later.

#551
no epic

A customer picks how to pay on the bill; online goes through the payment seam, cash keeps working.

#552
Backend v2

A customer can get a code on their phone and prove the number is theirs; the guest's orders stay with them.

#553
no epic

A customer turns on order alerts from You, on any phone.

#554
no epic

An online payment can be started, confirmed by a signed webhook and refunded on cancel, while cash on delivery stays as it is.

#555
no epic

An online order that is never paid does not stay stuck: the customer can switch to cash, and a payment not paid in 15 minutes fails on its own and the order goes back to cash.

#557
no epic

A customer who already has an account and opens the app on a new phone signs in with their number and keeps their old orders; whatever they ordered as a guest on the new phone moves over.

#558
no epic

A phone gets told when its order changes.

#561
no epic

A phone is really told when its order changes.

#563
no epic

A customer who chose to pay online can change their mind and pay cash, without waiting for the 15 minute expiry.

#565
no epic

The real Razorpay webhook can reach us.

#569
no epic

`orders.total_paise` means one thing everywhere: what the customer pays.

#572
no epic

The best offer is chosen for the customer by the server, and the customer can see the list.

#574