GoServe roadmap

updated 23:16 · 165 of 285 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.

Backend v2 24 done · 27 Oct to 27 Oct

Both apps talk to one server that owns every rule: prices, offers, hours, service area and payment.

The new server has a home that deploys by itself.
The apps and the server agree on every field in one file.
A customer signs in with their phone number and a code.
A customer can keep their name and email and can delete their data.
A customer saves addresses and picks one in a tap.
The app knows whether a kitchen can deliver to a place, and how soon.
The menu shows badges, tags and collections like a modern food app.
A dish can have choices, like spice level or extras, with limits.
The bill is computed in one place, so every app shows the same price.
The best offer is chosen for the customer by the server.
An order is placed once, with the price the customer saw.
A customer can pay by UPI or card, and cash on delivery still works.
Kitchens and riders move an order along through the new server.
A rider is chosen by the new server when food is ready.
Phones are told when something changes.
A customer sees the order and the rider move.
A late order gives the customer a coupon by itself.
A customer rates the food and the rider.
A customer finds answers without calling us.
Every call leaves a row, so problems can be found.
One person can run more than one kitchen: owner of one, staff in another, with one sign-in.
A customer who taps Place order twice, or whose phone retries after a drop, gets the order they already made, not an error.
The order total means one thing everywhere, so the kitchen, the rider, the numbers and the bill always agree.
A customer can get a code on their phone and prove the number is theirs; the guest's orders stay with them.

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) 25 of 28 · due 27 Oct · due today

M2 Design v2 approved 8 of 16 · due 28 Oct · 1 day left

M3 Backend v2 on dev project 45 of 45 · due 30 Oct · 3 days left

M4 Customer app, Android + iOS 5 of 59 · 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

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

The best offer is chosen for the customer by the server. #346 · no start time
The last layer of the offers (Remove on the Bill) and the list of layers of #346 are written down, so #346 and #311 can close with a clear record. #599 · no start time
A customer who does not want the offer taps Remove and pays the full price. #597 · no start time
The rehearsal checks what a customer really sees: the question "Yes, I have it" comes before the slip says Delivered. #593 · no start time
The first prod rehearsal, the offers stack and its tests must be written down so the next session knows what was run and what is open. #595 · no start time
A customer who removes an offer from the Bill pays without it. #589 · no start time
The customer sees the offers on the Bill, the best one first, and can apply one or type a code. #588 · no start time
A customer who got a "Sorry we were late" coupon can see it in their offers and use it. #579 · no start time
The order total means one thing everywhere, so the kitchen, the rider, the numbers and the bill always agree. #538 · no start time
Everything built in the 27 Oct stack (OTP, payments, push, coupons, ratings, profile, staff, help, on-time promise) must be written down, so the owner and the next session know what is done, what is a fake, and what the owner must click. #585 · no start time
The demo is rehearsed on the real app before the founder shows it, and each run leaves a record. #584 · no start time
A customer finds answers without calling us. #355 · no start time
One person can run more than one kitchen: owner of one, staff in another, with one sign-in. #468 · no start time
A customer can keep their name and email and can delete their data. #340 · no start time
A late order gives the customer a coupon by itself. #353 · no start time
A customer rates the food and the rider. #354 · no start time
A customer who taps Place order twice, or whose phone retries after a drop, gets the order they already made, not an error. #537 · no start time
The best offer is chosen for the customer by the server, and the customer can see the list. #574 · no start time
`orders.total_paise` means one thing everywhere: what the customer pays. #572 · no start time
The real Razorpay webhook can reach us. #569 · no start time
Phones are told when something changes. #351 · no start time
A phone is really told when its order changes. #563 · no start time
A customer turns on order alerts from You, on any phone. #554 · no start time
A customer who chose to pay online can change their mind and pay cash, without waiting for the 15 minute expiry. #565 · no start time
A customer picks how to pay on the bill; online goes through the payment seam, cash keeps working. #552 · no start time
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 start time
A customer can pay by UPI or card, and cash on delivery still works. #348 · no start time
A phone gets told when its order changes. #561 · no start time
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 start time
A customer signs in with their phone number and a code. #339 · no start time
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 · 19 min
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 start time
When the owner is ready, each service takes him one click. #544 · no start time
A customer can get a code on their phone and prove the number is theirs; the guest's orders stay with them. #553 · no start time
A customer sees the order and the rider move. #352 · 58 min
Everything the coder did and learned on 27 Oct is written down, so the next session finds it and repeats no mistake. #545 · no start time
A rider is chosen by the new server when food is ready. #350 · 42 min
Every call leaves a row, so problems can be found. #356 · 32 min
A slow database moment must not skip a tick of the simulator, the dispatcher, the push drain or the daily numbers. #541 · no start time
Kitchens and riders move an order along through the new server. #349 · 32 min
An order is placed once, with the price the customer saw. #347 · 27 min
A slow database moment must not skip a push round. #532 · no start time
The app says "Good morning!" to a stranger, and "Good morning, Priya." only once it knows her name. #527 · no start time
On the thali toggle, the veg and non-veg marks stay readable, and the chosen side is still clear. #528 · no start time
The app knows whether a kitchen can deliver to a place, and how soon. #342 · 17 min
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 · no start time
A customer saves addresses and picks one in a tap. #341 · 14 min
The bill is computed in one place, so every app shows the same price. #345 · 6 min
A dish can have choices, like spice level or extras, with limits. #344 · 2 min
Every closed story shows its cycle time on the roadmap, even the 92 that closed before the `doing` label existed. #518 · no start time
The menu shows badges, tags and collections like a modern food app. #343 · 3 min
The apps and the server agree on every field in one file. #338 · 30 min
The new server has a home that deploys by itself. #337 · 8 min
A reviewer mistake the owner corrected must teach the next session: the light zigzag colour is deliberate. #513 · 3 min
The owner's round-2 motion feedback must not be lost. #511 · 15 min
The owner's own Swish screen is the best source we have. #509 · 9 min
The owner's Night lamp idea and the motion framework must be kept in the repo, and today's records written down. #506 · 3 min
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 · 31 min
The customer must hear when the rider picks up the food. #500 · 5 min
We know exactly what a good quick-food app does at each step. #330 · 4 h 8 min
There is one roadmap. #497 · 4 min
The release, the daily limits card and the n8n publish rule must be written down so any session can find them. #495 · 7 min
One way to do a thing, never two (owner rule, 27 Oct). #485 · 56 min
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 · 26 min
The decisions, rules and research of 27 Oct must be written down so any session can find them. #489 · 9 min
The customer must know when the food comes, with the app closed. #483 · 45 min
When something goes wrong on a phone, we must see what happened to that order, in order, from real logs. #484 · 31 min
Nothing the customer must tap hides under the iPhone home bar or the status bar. #481 · 16 min
We learn from good open examples and know how far to trust each source. #329 · 5 min
The Android app follows its own platform's rules and matches iOS. #328 · 12 min
Our design starts from what Apple has learned about clear apps. #327 · 18 min
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 · 11 min

26 Oct

When the admin does something that cannot be done, the screen says why in words he can read. #466 · 46 min
The Simulator tab looks as well made as the rest of the admin, so the founder is not embarrassed when he shows it. #461 · 55 min
A customer is never asked "Was your order delivered?" while the kitchen is still cooking. #456 · 7 min
The founder turns on one "demo mode" switch before a demo. #454 · 1 h 55 min
A customer who sees a kitchen closed in the middle of the day is told the truth, not that it opens tomorrow morning. #452 · 26 min
The founder can show GoServe in ten steps and know what to say. #323 · 15 min
A customer on a pin code we do not serve is told so kindly. #322 · 52 min
A customer cannot order from a kitchen that is closed. #321 · 1 h 12 min
The founder's iPhone always shows the newest version of the app. #320 · 9 min
The whole plan is one list of small stories that anyone can read and pick from. #317 · 4 h 8 min
Everyone can see which branch holds what, and every story has the labels it needs. #316 · 4 h 8 min
Anyone with a link sees where GoServe is today, what is next, and what waits on what, on a phone. #319 · 47 min
Each goal has a date and a check that anyone can measure. #318 · 6 min

25 Oct

The admin picks who makes the live decisions: Rules, Jev or Laya. #263 · 4 h 8 min
Nothing paid runs when nobody asked for it. #253 · 4 h 8 min
Google Play asks for a privacy page before it lets testers install. #302 · 25 min
When someone opens a demo kitchen's menu, every dish shows a real, good-looking photo. #292 · 4 h 8 min
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 · 4 h 8 min
The admin sets parameters, seeds, resets and switches the tick on and off, and sees counts. #190 · 4 h 8 min
A scheduled tick moves synthetic riders and flips synthetic kitchens and dishes while the simulator is on. #189 · 4 h 8 min
One n8n API seeds synthetic kitchens, riders and dishes from parameters and one resets them. #188 · 4 h 8 min
An order on a demo kitchen moves like a real one: accepted, cooked, picked up and delivered by a moving rider. #284 · 2 h 53 min
A customer on a real Delhi pin sees the demo kitchens and gets a rider, for every kitchen, the two old ones too. #283 · 2 h 53 min
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 · 2 h 53 min
Anyone can download the latest GoServe app from one page and install it. #251 · 4 h 8 min
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 · 4 h 8 min
The menu looks right again: photo on the left, name and price in the middle, Add on the right, open or closed. #274 · 4 h 8 min
When an order is ready, the nearest free rider gets it, so the food waits less and reaches the door sooner. #272 · 4 h 8 min
The demo ran 20 times out of 20, on the founder's Android phone, with a backup video. #56 · 4 h 8 min
letsdwelo.in shows three pages in the Ink v3 look: Home, For investors, Pre-register. #200 · 4 h 8 min
Every app shows only its board. #242 · 1 h 40 min
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 · 2 h 7 min
The cook wants to know who is coming for a ready order, not just that someone is. #231 · 3 h 31 min
A cook who already started a dish must know the order was cancelled, not just see it vanish. #230 · 3 h 31 min
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 · 3 h 31 min
The app opens in Day for everyone until the owner says otherwise. #225 · 4 h 4 min
A customer never signs in. #224 · 4 h 5 min
A tech investor can read what GoServe is built of in one README. #206 · 4 h 8 min
The owner sees the platform's health and what it costs. #205 · 4 h 8 min
The owner gets a pilot report and a watch on the pilot's numbers. #204 · 4 h 8 min
The winning skill applied to admin tables and forms. #195 · 4 h 8 min
The winning skill applied to the rider and kitchen apps, one-thumb. #194 · 4 h 8 min
The winning skill applied to every customer screen. #193 · 4 h 8 min
A staff user belongs to one kitchen, and the kitchen app says so loudly when the account is not staff. #186 · 4 h 8 min
The demo console at `/` and the other role apps cannot place orders or read menus on prod. #185 · 4 h 8 min
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 · 4 h 8 min
The customer app passes the benchmark table. #161 · 4 h 8 min
One set of components and tokens for every screen. #160 · 4 h 8 min
The customer has an account-like experience on a cash order. #159 · 4 h 8 min
A customer orders from a kitchen that serves their area. #158 · 4 h 8 min
A refresh must not lose the customer's place. #157 · 4 h 8 min
The customer learns about the order without keeping the app open. #154 · 4 h 8 min
A kitchen controls what a customer can order right now. #153 · 4 h 8 min
Each order goes to one rider, chosen by rule, and the rider sees only their own orders. #152 · 4 h 8 min
The founder sees the day and can stop a bad order. #151 · 4 h 8 min
Each kitchen's menu is managed by the founder, with real photos. #150 · 4 h 8 min
The founder adds a kitchen and its people without touching the database. #149 · 4 h 8 min
Everything else needs one data model that holds many kitchens, customers, riders and admins. #148 · 4 h 8 min
A rider signs in with Google and sees their own deliveries. #135 · 4 h 8 min
A kitchen worker signs in with Google and sees their own kitchen. #132 · 4 h 8 min
The app has privacy and terms pages, so Google sign-in can show them. #123 · 4 h 8 min
MVP 1 is closed with a gate log, a closure note and a release. #119 · 4 h 8 min
No order is lost or doubled, even when the network drops, and we proved it. #118 · 4 h 8 min
A customer can sign in with Google and keep the orders they placed before signing in. #117 · 4 h 8 min

22 Oct

Customer, kitchen, rider and ops each get their own installable app, from one codebase. #83 · 4 h 8 min
Production is ready: its own database, app address and workflows, before the first real demo. #78 · 4 h 8 min
Nobody delivers in the UAT. #95 · 4 h 8 min
A tester sees something odd and tells us in ten seconds, without leaving the app and without WhatsApp. #94 · 4 h 8 min

14 Oct

The owner gets a daily scorecard on Telegram without asking. #47 · 4 h 8 min
One page shows whether Supabase, n8n and Jev are up, before a demo. #54 · 4 h 8 min
The demo plays by itself even with no internet. #53 · 4 h 8 min
The demo shows all four roles side by side, each in its own space, with a reset. #52 · 4 h 8 min
The founder sees the system's suggestion and the day's numbers on one ops screen. #51 · 4 h 8 min
The rider walks the delivery steps, and the customer sees the status up to Delivered. #50 · 4 h 8 min
The kitchen sees live orders and moves each one with Accept, Start and Ready. #49 · 4 h 8 min
A customer can open the menu, fill a cart, see the bill and place an order. #48 · 4 h 8 min
The system suggests a decision on each order and keeps a log of what it decided. #46 · 4 h 8 min
An order can be placed and moved through its steps by the workflows, with every step logged. #45 · 4 h 8 min
Each person sees only their own data, the kitchen sees new orders live, and Delhi has a sample menu. #44 · 4 h 8 min
The database has the seven tables the order needs, and refuses an illegal order step. #43 · 4 h 8 min
A release to main puts the app on its public address by itself. #42 · 4 h 8 min
Every push to the dev branch gives the owner a live dev site to look at. #41 · 4 h 8 min
Every change to the app is checked by a machine before anyone can merge it. #40 · 4 h 8 min
The app exists, installs on a phone, and uses the brand's colours from one file. #39 · 4 h 8 min

13 Oct

Every lead from the investor site is saved and sent to us at once, so no lead is lost. #5 · 4 h 8 min
Before every MVP phase there is a gate: we stop and check that the setup is ready. #22 · 13 min
Before the first build, every missing part is known, and the options for each are written down. #20 · 13 min
Delhi is the first city on the site, and every colour and font has one home. #18 · 4 min
Investors can see how GoServe grows from a demo to a city, one page, one phase at a time. #16 · 38 min
There is one list of every part of the system, by phase. #13 · no start time

11 Oct

There is one place for every learning and mistake, and the process uses it. #10 · no start time
Every lead alert comes from our own bot, GoServeBot. #8 · no start time
The lead alert on Telegram and the saved lead show every field, not blanks. #6 · no start time

Now

Nothing is being built right now.

The demo has been run twice before the founder shows it. #324 · M1 MVP2 demo-ready (PWA, frozen) · P0 ready
The owner has tried every feature on his own phone. #325 · M1 MVP2 demo-ready (PWA, frozen) · P0 blocked by #324
The demo version is safe and stays as it is. #326 · M1 MVP2 demo-ready (PWA, frozen) · P0 blocked by #325
Both apps get the same colours, type and spacing from one file. #332 · M2 Design v2 approved · P0 blocked by #331
The owner can see the customer app before it is built. #333 · M2 Design v2 approved · P0 blocked by #332
The owner can see the staff apps before they are built. #334 · M2 Design v2 approved · P0 blocked by #332
Every screen has been asked five hard questions. #335 · M2 Design v2 approved · P0 blocked by #333, #334
The owner agrees to the look before any app is built. #336 · M2 Design v2 approved · P0 blocked by #335
The team shares seven simple rules and one big idea for the look of the app. #331 · M2 Design v2 approved · P1 ready
Every change to the app is built and tested by itself. #357 · M4 Customer app, Android + iOS · P0 ready
One app opens for customer, kitchen, rider and admin. #358 · M4 Customer app, Android + iOS · P0 blocked by #357
The app looks like our design because the theme comes from one file. #359 · M4 Customer app, Android + iOS · P0 blocked by #358, #332
The app talks to the server with code made from the contract. #360 · M4 Customer app, Android + iOS · P0 blocked by #358
Testers install the app from the store in one tap. #361 · M4 Customer app, Android + iOS · P0 blocked by #357
A customer signs in with a phone number and a code. #363 · M4 Customer app, Android + iOS · P0 blocked by #360
A customer says where to deliver by pin on a map. #364 · M4 Customer app, Android + iOS · P0 blocked by #360
A customer adds house details once and reuses them. #365 · M4 Customer app, Android + iOS · P0 blocked by #364
A customer outside our area is told kindly and can ask us to come. #366 · M4 Customer app, Android + iOS · P0 blocked by #360
A customer sees an honest ETA and the food at once. #367 · M4 Customer app, Android + iOS · P0 blocked by #359
A customer browses one kind of food. #368 · M4 Customer app, Android + iOS · P0 blocked by #367
A customer sees what a dish is and whether it is available. #369 · M4 Customer app, Android + iOS · P0 blocked by #367
A customer picks the choices of a dish. #370 · M4 Customer app, Android + iOS · P0 blocked by #369
A customer always sees what is in the cart. #371 · M4 Customer app, Android + iOS · P0 blocked by #367
A customer sees the whole bill as one slip, with the savings. #372 · M4 Customer app, Android + iOS · P0 blocked by #371
A customer pays by UPI, card or cash. #373 · M4 Customer app, Android + iOS · P0 blocked by #372
A customer watches the order become a delivery. #374 · M4 Customer app, Android + iOS · P0 blocked by #373
A customer finds past orders and orders again in one tap. #376 · M4 Customer app, Android + iOS · P0 blocked by #372
Every change to the app is built and tested by itself. #395 · M4 Customer app, Android + iOS · P0 ready
One app opens for customer, kitchen, rider and admin. #396 · M4 Customer app, Android + iOS · P0 blocked by #395
The app looks like our design because the theme comes from one file. #397 · M4 Customer app, Android + iOS · P0 blocked by #396, #332
The app talks to the server with code made from the contract. #398 · M4 Customer app, Android + iOS · P0 blocked by #396
Testers install the app from the store in one tap. #399 · M4 Customer app, Android + iOS · P0 blocked by #395
A customer signs in with a phone number and a code. #401 · M4 Customer app, Android + iOS · P0 blocked by #398
A customer says where to deliver by pin on a map. #402 · M4 Customer app, Android + iOS · P0 blocked by #398
A customer adds house details once and reuses them. #403 · M4 Customer app, Android + iOS · P0 blocked by #402
A customer outside our area is told kindly and can ask us to come. #404 · M4 Customer app, Android + iOS · P0 blocked by #398
A customer sees an honest ETA and the food at once. #405 · M4 Customer app, Android + iOS · P0 blocked by #397
A customer browses one kind of food. #406 · M4 Customer app, Android + iOS · P0 blocked by #405
A customer sees what a dish is and whether it is available. #407 · M4 Customer app, Android + iOS · P0 blocked by #405
A customer picks the choices of a dish. #408 · M4 Customer app, Android + iOS · P0 blocked by #407
A customer always sees what is in the cart. #409 · M4 Customer app, Android + iOS · P0 blocked by #405
A customer sees the whole bill as one slip, with the savings. #410 · M4 Customer app, Android + iOS · P0 blocked by #409
A customer pays by UPI, card or cash. #411 · M4 Customer app, Android + iOS · P0 blocked by #410
A customer watches the order become a delivery. #412 · M4 Customer app, Android + iOS · P0 blocked by #411
A customer finds past orders and orders again in one tap. #414 · M4 Customer app, Android + iOS · P0 blocked by #410
A new customer sees what the app does in three slides. #362 · M4 Customer app, Android + iOS · P1 blocked by #359
The order shows on the lock screen. #375 · M4 Customer app, Android + iOS · P1 blocked by #374
A customer rates after delivery. #377 · M4 Customer app, Android + iOS · P1 blocked by #374
A customer manages their profile and gets help. #379 · M4 Customer app, Android + iOS · P1 blocked by #365
A customer hears when the order changes. #380 · M4 Customer app, Android + iOS · P1 blocked by #374
The app never shows a blank page. #381 · M4 Customer app, Android + iOS · P1 blocked by #367
People with different needs can use the app. #382 · M4 Customer app, Android + iOS · P1 blocked by #381, #380, #379
A new customer sees what the app does in three slides. #400 · M4 Customer app, Android + iOS · P1 blocked by #397
The order shows on the lock screen. #413 · M4 Customer app, Android + iOS · P1 blocked by #412
A customer rates after delivery. #415 · M4 Customer app, Android + iOS · P1 blocked by #412
A customer manages their profile and gets help. #416 · M4 Customer app, Android + iOS · P1 blocked by #403
A customer hears when the order changes. #417 · M4 Customer app, Android + iOS · P1 blocked by #412
The app never shows a blank page. #418 · M4 Customer app, Android + iOS · P1 blocked by #405
People with different needs can use the app. #419 · M4 Customer app, Android + iOS · P1 blocked by #418, #417, #416
Kitchen staff sign in with Google and pick their kitchen. #383 · M5 Kitchen + rider apps · P0 blocked by #360
The kitchen hears a new order and accepts it. #384 · M5 Kitchen + rider apps · P0 blocked by #383
The cook sees exactly what to make. #385 · M5 Kitchen + rider apps · P0 blocked by #384
The kitchen controls what customers can order. #386 · M5 Kitchen + rider apps · P0 blocked by #383
A rider signs in and goes on duty. #387 · M5 Kitchen + rider apps · P0 blocked by #360
A rider walks through pickup to delivered, with cash or prepaid. #388 · M5 Kitchen + rider apps · P0 blocked by #387
The customer sees the rider move even when the rider's screen is off. #389 · M5 Kitchen + rider apps · P0 blocked by #387
Kitchen staff sign in with Google and pick their kitchen. #420 · M5 Kitchen + rider apps · P0 blocked by #398
The kitchen hears a new order and accepts it. #421 · M5 Kitchen + rider apps · P0 blocked by #420
The cook sees exactly what to make. #422 · M5 Kitchen + rider apps · P0 blocked by #421
The kitchen controls what customers can order. #423 · M5 Kitchen + rider apps · P0 blocked by #420
A rider signs in and goes on duty. #424 · M5 Kitchen + rider apps · P0 blocked by #398
A rider walks through pickup to delivered, with cash or prepaid. #425 · M5 Kitchen + rider apps · P0 blocked by #424
The customer sees the rider move even when the rider's screen is off. #426 · M5 Kitchen + rider apps · P0 blocked by #424
A rider sees their day. #390 · M5 Kitchen + rider apps · P1 blocked by #387
A rider sees their day. #427 · M5 Kitchen + rider apps · P1 blocked by #424
A person who works in two kitchens picks which one they are serving, and can switch without signing out. #469 · M5 Kitchen + rider apps · P1 blocked by #383
A person who works in two kitchens picks which one they are serving, and can switch without signing out. #470 · M5 Kitchen + rider apps · P1 blocked by #420
People can find and trust the app in the stores. #432 · M6 Admin + launch hardening · P0 blocked by #362, #363, #364, #365, #366, #367, #368, #369, #370, #371, #372, #373, #374, #375, #376, #377, #379, #380, #381, #382, #400, #401, #402, #403, #404, #405, #406, #407, #408, #409, #410, #411, #412, #413, #414, #415, #416, #417, #418, #419
The owner has tried everything on both phones. #433 · M6 Admin + launch hardening · P0 blocked by #357, #358, #359, #360, #361, #362, #363, #364, #365, #366, #367, #368, #369, #370, #371, #372, #373, #374, #375, #376, #377, #379, #380, #381, #382, #383, #384, #385, #386, #387, #388, #389, #390, #391, #392, #393, #394, #395, #396, #397, #398, #399, #400, #401, #402, #403, #404, #405, #406, #407, #408, #409, #410, #411, #412, #413, #414, #415, #416, #417, #418, #419, #420, #421, #422, #423, #424, #425, #426, #427, #428, #429, #430, #431
Version 2 is released. #434 · M6 Admin + launch hardening · P0 blocked by #433
The admin sees every order and can cancel one. #391 · M6 Admin + launch hardening · P1 blocked by #360
The admin runs the city. #392 · M6 Admin + launch hardening · P1 blocked by #391
The admin changes menus, add-ons and offers. #393 · M6 Admin + launch hardening · P1 blocked by #391
The admin sees the numbers and the demo city. #394 · M6 Admin + launch hardening · P1 blocked by #391
The admin sees every order and can cancel one. #428 · M6 Admin + launch hardening · P1 blocked by #398
The admin runs the city. #429 · M6 Admin + launch hardening · P1 blocked by #428
The admin changes menus, add-ons and offers. #430 · M6 Admin + launch hardening · P1 blocked by #428
The admin sees the numbers and the demo city. #431 · M6 Admin + launch hardening · P1 blocked by #428

Older open work

32 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
The price the customer sees on the Bill is the price of the order, with fees, tax and offers. #590

Board

To do 120

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 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)

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

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

no epic

The price the customer sees on the Bill is the price of the order, with fees, tax and offers.

#590

Doing 0

Review 0

Done 165

investor doorway site (letsdwelo.in)

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

investor doorway site (letsdwelo.in)

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

investor doorway site (letsdwelo.in)

Every lead alert comes from our own bot, GoServeBot.

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

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

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

Backend v2

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

#538

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

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

no epic

Everything built in the 27 Oct stack (OTP, payments, push, coupons, ratings, profile, staff, help, on-time promise) must be written down, so the owner and the next session know what is done, what is a fake, and what the owner must click.

#585

no epic

The customer sees the offers on the Bill, the best one first, and can apply one or type a code.

#588

no epic

A customer who removes an offer from the Bill pays without it.

#589

no epic

The rehearsal checks what a customer really sees: the question "Yes, I have it" comes before the slip says Delivered.

#593

no epic

The first prod rehearsal, the offers stack and its tests must be written down so the next session knows what was run and what is open.

#595

no epic

A customer who does not want the offer taps Remove and pays the full price.

#597

no epic

The last layer of the offers (Remove on the Bill) and the list of layers of #346 are written down, so #346 and #311 can close with a clear record.

#599

GoServe roadmap

Vision

Delivered

You are here

Milestones

What waits for what

Timeline

27 Oct

26 Oct

25 Oct

22 Oct

14 Oct

13 Oct

11 Oct

Now

Next

Older open work

Board

To do 120

Doing 0

Review 0

Done 165