TL;DR

Last-mile Delivery Platform — tai vietinio prekių pristatymo iki galutinio vartotojo durų platforma. Regionas — Majamis ir jo priemiesčiai, Florida. Klientas pateikia užsakymą per svetainę arba Telegram, ir per 30–90 minučių prekę atveža vairuotojas.

Platforma yra multi-tenant: viena kodo bazė aptarnauja kelias parduotuves viename regione. Viduje gyvena šešios vartotojų rolės, penkios sąveikos sąsajos, trys Telegram botai, lojalumo programa su pinigine ir cashback, rekomendacijų sistema su QR kampanijomis, šešios pristatymo zonos su savomis taisyklėmis ir šeši mokėjimo būdai — nuo grynųjų iki kriptovaliutos.

Pagrindiniai skirtumai nuo tipinės parduotuvės su kurjeriais: realus real-time vairuotojo stebėjimas, automatinė grynųjų pinigų sutikrinimo procedūra pamainos pabaigoje, premium prenumerata su bonusais ir išplėstomis galimybėmis, analitika session replay ir audit trail lygiu. Siekiant atitikti amerikietiškas komunikacijos taisykles — kliento KYC verifikacija, asmens duomenų maskavimas ir registracija Twilio A2P sistemoje.

Last-mile Delivery Platform — verslo logika

Kas tai per platforma

Įsivaizduokite įprastą parduotuvę netoli namų. Jūs užėjote, išsirinkote prekes, sumokėjote, išsinešėte. O dabar įsivaizduokite, kad tarp jūsų ir parduotuvės atsirado technologijų sluoksnis: jūs nebeateinate kojomis — atidarote svetainę ar Telegram, krepšelis surenkamas telefone, mokėjimas atliekamas vienu paspaudimu, o po valandos kurjeris skambina į duris. Tai ir yra last-mile delivery: „paskutinė mylia" nuo parduotuvės sandėlio iki kliento durų.

Last-mile Delivery Platform daro būtent tai vienu metu kelioms parduotuvėms. Klientas registracijos metu praeina KYC verifikaciją. Parduotuvė laikosi teritorinių apribojimų pagal ZIP kodus. Vairuotojas veža ne tik prekę, bet ir grynuosius atgal — vadinasi, platforma skaičiuoja kiekvieną dolerį iki paskutinio cento.

Architektūriškai tai multi-tenant sistema: viena ir ta pati kodo bazė vienu metu aptarnauja kelias parduotuves. Kiekviena parduotuvė mato tik savo užsakymus, savo klientus, savo prekes ir savo darbuotojus. Po variklio dangčiu tai reiškia, kad bet kuri užklausa į duomenų bazę filtruojama pagal store_id, ir nė vienas vienos parduotuvės darbuotojas negali atsitiktinai pamatyti kitos parduotuvės duomenų.

Su platforma sąveikaujama per penkias skirtingas sąsajas. Pagrindinis kanalas — viešoji svetainė-vitrina, per kurią užsakymus pateikia dauguma klientų. Toliau eina keturios Telegram aplikacijos: viena pirkėjams (mini-parduotuvė Telegram viduje), antra dispečeriams (mato visus įeinančius užsakymus, priskiria vairuotojus), trečia vairuotojams (gauna savo pristatymus, žymi statusus), ir verslo administracinė pultas — ten vadybininkai ir savininkai mato ataskaitas, valdo prekes, kainas ir darbuotojus.

Sistemoje yra šešios rolės: platform_admin (platformos savininkas — gali viską), store_admin (konkrečios parduotuvės administratorius), manager (vadybininkas be kai kurių teisių), dispatcher (dispečeris — paskirsto užsakymus vairuotojams), driver (vairuotojas), customer (pirkėjas).

Lygiagrečiai su sąsajomis veikia trys Python botai Telegram platformoje — klientams, vairuotojams ir dispečeriams. Botai nerodo gražių ekranų: jų užduotis — akimirksniu pristatyti pranešimą ir suteikti minimalų komandų rinkinį.

Kaip veikia užsakymas nuo pradžios iki pabaigos

1 žingsnis. Vitrina ir katalogas

Klientas užeina į svetainę. Pagrindiniame puslapyje — hero-blokas, dienos baneriai, prekių kategorijos (iš viso 10 kategorijų). Klientas spaudžia ant kategorijos, patenka į sąrašą, toliau — prekės kortelė su nuotraukomis, aprašymu, atsiliepimais ir variantais (kiekiai, pakuotės, rinkiniai).

Krepšelis sutvarkytas įdomiai: iki užsakymo pateikimo momento jis gyvena localStorage kliento naršyklėje. Tai reiškia, kad neregistruotas vartotojas gali prisidėti į krepšelį, uždaryti skirtuką, grįžti po valandos — ir viskas vietoje. Checkout momentu krepšelis išvažiuoja į serverį ir priskiriamas vartotojui (po registracijos/prisijungimo).

2 žingsnis. Adresas ir pristatymo zona

Klientas įveda adresą. Sistema paima ZIP kodą ir ieško jo pristatymo zonų lentelėje. Zonos yra šešios: Majamio centras, Coral Gables ir dar keturios. Kiekviena zona turi savo taisykles — minimalią užsakymo sumą, orientacinį pristatymo laiką, papildomą mokestį už atstumą.

Jei ZIP nepatenka nė į vieną zoną — klientas mato draugišką pranešimą „mes dar nepristatome į jūsų rajoną" ir pasiūlymą palikti el. paštą, kad sužinotų apie plėtrą.

Pristatymo zona — tai ne tik poligonas žemėlapyje. Tai verslo taisyklė: „pagal šį ZIP kodą nuo tokios sumos, su tokiu greičiu, su tokiais apribojimais".

3 žingsnis. Pristatymo laikas

Toliau — laiko pasirinkimas. Du režimai. Pirmas — express (ASAP): vairuotojas paima užsakymą iškart, kai gali, pristatymas orientaciniai 30–90 minučių. Antras — scheduled time slot: 15 minučių laiko langai artimiausioms dienoms. Kiekvienas laiko langas turi talpos limitą (capacity) — po X užsakymų laiko langas uždaromas, kad nebūtų perkrauti vairuotojai.

Virš to veikia traffic windows — kamščių langai. Tai taisyklės administracijoje: „ZIP 33129 nepristatomas nuo 17:00 iki 19:00 darbo dienomis". Jei klientas pasirenka laiką ir zoną, patenkančią į tokį langą, jo laiko langas bus nepasiekiamas.

4 žingsnis. Mokėjimas

Mokėjimo būdai — tai atskira istorija. Platforma priima šešis tipus: Cash on Delivery (grynieji kurjeriui), Zelle, CashApp, Venmo, vidinę piniginę (wallet) ir kriptovaliutą penkiais pavidalais — BTC (per xpub raktą), ETH, USDT, USDC, USDT TRC-20.

Klientas gali derinti: pavyzdžiui, dalį apmokėti pinigine (nurašyti cashback), dalį — grynaisiais.

5 žingsnis. Akcijos kodas

Akcijos kodo laukelis. Sistema validuoja kodą — tikrina galiojimo terminą, panaudojimų limitą, minimalią sumą, priskyrimą konkrečiam klientui. Palaikomi šeši akcijos kodų tipai: procentinė nuolaida, fiksuota suma, nemokama prekė dovanai, cashback į piniginę, military discount (nuolaida kariškiams su verifikacija), pirmas užsakymas.

6 žingsnis. Užsakymas sukurtas

Klientas spaudžia „Pateikti". Užsakymas sukuriamas duomenų bazėje su statusu PENDING. Ir iškart paleidžiamas pranešimų kaskadas.

Per Pushover servisą dispečeriams išsiunčiamas push pranešimas su 2 prioritetu — tai reiškia, kad dispečerio telefonas skambės garsiai ir ilgai (iki 30 sekundžių), kol tas patvirtins. Lygiagrečiai botas Telegram atsiunčia trumpą žinutę su nuoroda į užsakymą.

7 žingsnis. Dispečeris priskiria vairuotoją

Dispečeris mato užsakymą arba administracijoje, arba savo Telegram mini-app. Viduje — sudėtis, adresas, laikas, mokėjimo būdas, kliento pastabos. Dispečeris išsirenka vairuotoją iš laisvų sąrašo ir priskiria užsakymą.

Statusas keičiasi: PENDING → CONFIRMED → READY → ASSIGNED. Vairuotojui atskrenda push (taip pat Pushover, taip pat garsiai) — „naujas užsakymas".

8 žingsnis. Vairuotojas pakeliui

Vairuotojas atidaro savo mini-app, mato detales — parduotuvės adresą iš kur paimti, kliento adresą kur vežti, maršrutą žemėlapyje. Važiuoja į parduotuvę, žymi „Picked up" (statusas PICKED_UP). Važiuoja pas klientą.

Visą šį laiką klientas mato savo aplikacijoje real-time tracking: vairuotojo tašką žemėlapyje ir apskaičiuotą atvykimo laiką (ETA). Vairuotojo geopozicija lekia per WebSocket kas kelias sekundes, ETA perskaičiuojamas pagal geokodavimą.

9 žingsnis. Pristatymas ir atsiliepimas

Vairuotojas atvyko, atidavė prekę, paėmė mokėjimą (jei COD), paspaudė „Delivered". Statusas — DELIVERED. Dispečeriui nukrenta push su 1 prioritetu (normalus, be sirenos): „užsakymas pristatytas".

Klientui po kelių minučių ateina prašymas dėl atsiliepimo: įvertinti užsakymą ir/arba konkrečias prekes.

Lojalumo ir išlaikymo programa

Klientų išlaikymas — tai ne viena funkcija, o visas susipynusių mechanikų rinkinys. Apie kiekvieną papasakosiu atskirai, bet realybėje jos veikia kartu.

Wallet — vidinė piniginė

Po kiekvieno užsakymo klientui priskaičiuojamas cashback — procentas nuo sumos. Šis procentas priklauso nuo kliento lygio (apie lygius žemiau). Cashback krenta į vidinę piniginę ir gali būti panaudotas kitame užsakyme kaip mokėjimo dalis.

Kiekviena operacija su pinigine — atskira transakcija duomenų bazėje. Priskaičiavimas, nurašymas, grąžinimas, administratoriaus korekcija. Visą istoriją mato ir pats klientas asmeniniame kabinete, ir administratorius administracijoje.

Piniginė — tai ne tik bonuso taškai. Tai tikri pinigai doleriais, kuriuos klientas jau išleido, bet gavo dalį atgal kaip motyvaciją grįžti.

Affiliate program — rekomendacijų programa

Kiekvienam registruotam klientui automatiškai generuojamas unikalus rekomendacijų kodas. Klientas gali pasidalinti nuoroda ?ref=CODE — draugas pereina, registruojasi, padaro užsakymą, ir pakvietusysis gauna komisinius į savo piniginę.

QR kodai generuojami automatiškai. Pagrindiniame hero puslapyje autorizuotiems klientams yra paruoštas QR — nukreipk telefoną, pasidalink.

Customer plans / Premium tier — klientų lygiai

Trys lygiai: bronze, silver, gold. Bronze — pradinis, suteikiamas visiems registracijos metu. Silver ir gold — mokamos prenumeratos arba pasiekiami pagal apyvartą. Kuo aukštesnis lygis, tuo daugiau privalumų:

• Padidintas cashback procentas
• Prieiga prie unikalių mokėjimo metodų (pavyzdžiui, kriptovaliuta gali būti uždaryta bronze lygiui)
• 24/7 užsakymai — bypass įprastoms parduotuvės darbo valandoms
• Bypass ZIP-restrictions — išplėsta pristatymo zona
• Bonusinės prekės prisijungus prie lygio

Promo codes masiniais batch'ais

Marketologas gali vienu mygtuko paspaudimu sugeneruoti 1000 unikalių akcijos kodų ir išgrupuoti juos CSV failu. Scenarijus: atspausdinti ant lankstinuko ir išdalinti gatvėje, prisegti prie užsakymo kaip siurprizą, panaudoti reklaminėje kampanijoje. Kiekvienas kodas — single-use arba multi-use, procentas arba suma, su konfigūruojamu limitu pagal užsakymo sumą.

QR kampanijos

Atskira mechanika offline-marketingui. Marketologas sukuria kampaniją, priskiria jai akcijos kodą, gauna trumpą URL /c/CODE. Klientas skenuoja QR — patenka į svetainę — akcijos kodas jau pritaikytas, srauto šaltinis užfiksuotas.

Toliau — analitika: kiek skenavimų, kiek konversijų, kiek pajamų atnešė kampanija, vidutinis čekis šioje kampanijoje. Galima lyginti kampanijas tarpusavyje ir suprasti, kuris kanalas atsiperka.

Day-of-week akcijos

Paprasta, bet veikianti taisyklė: „pirmadienis — 15% nuolaida viskam". Konfigūruojama administracijoje: savaitės diena, nuolaidos procentas, minimali užsakymo suma. Pasirinktinai: pridėti nemokamą prekę arba priskaičiuoti papildomą cashback.

Mix & Match — paketinės nuolaidos

Nuolaidos tipas „pirk N — gauk %". Keletas pakopų: nupirkai 3 — 20% nuolaida, nupirkai 5 — 30%. Priskyrimas pagal kategorijas ar konkrečias prekes. Galima sukurti „paimk tris bet kokius iš šios kategorijos — gauk nuolaidą".

Banners — dinaminiai baneriai

Pagrindiniame puslapyje — baneriai, skirtingi mobiliajai ir desktop versijai. Kiekvienas baneris turi savo target URL: veda arba į kategoriją, arba į akcijų puslapį. Vadybininkas valdo banerius administracijoje be programuotojo pagalbos.

Reviews

Klientas palieka atsiliepimus apie užsakymus ir atskirai — apie konkrečias prekes. Reitingai rodomi prekių kortelėse ir formuoja „pasitikėjimo leitmotyvą" — socialinį įrodymą naujiems klientams.

Komunikacijos su klientu kanalai

WhatsApp-first messaging

Pagrindinis kanalas transakciniams pranešimams (užsakymo patvirtinimas, pristatymo statusai) — WhatsApp. Po variklio dangčiu — multi-node gateway: iki 5 mazgų (fizinių įrenginių su WhatsApp Business), kurie veikia round-robin schema su sticky session — tai yra tas pats klientas visada gauna pranešimus iš to paties mazgo.

Jei WhatsApp nepasiekė (klientas ištrynė programėlę, užblokavo numerį, nėra interneto), sistema automatiškai daro fallback į SMS.

SMS — du kanalai

SMS siunčiamos dviem keliais. Pirmas — Twilio A2P: komercinė kampanijos registracija JAV, reikalinga atitikti amerikietiškų operatorių taisykles. Šios platformos aprašymo metu kampanija pateikta ir vyksta TCR vetting (2–3 savaitės).

Antras kanalas — SMS Gate: Android aplikacija fiziniuose įrenginiuose, kurie siunčia SMS kaip iš įprastų numerių. Taip pat round-robin tarp įrenginių. Naudojama pirmiausia OTP kodams registracijos ir prisijungimo metu.

Email

Email — forgot-password ir retiems masiniams laiškams. Ne pagrindinis kanalas — didžioji dauguma klientų informaciją gauna WhatsApp/Telegram.

Pushover komandai

Komanda (dispečeriai, vairuotojai, savininkai) gauna pranešimus per Pushover. Tai ne kliento kanalas — tai vidinis įrankis. Trys prioriteto lygiai:

• Naujas užsakymas → dispečeriams, priority=2 (garsi sirena 30 sekundžių iki patvirtinimo — kritiškai svarbu, kad užsakymai neprapultų)
• Užsakymas priskirtas → vairuotojui, priority=2 (garsus pranešimas)
• Užsakymas pristatytas → dispečeriams, priority=1 (normalus garsas)

Telegram botai

Trys atskiri botai:

• Pirkėjo botas — lengvas užsakymo kanalas neužeinant į svetainę
• Dispečerio botas — atsarginis kanalas, jei Pushover nepasiekiamas
• Vairuotojo botas — operatyvūs pranešimai apie naujus pristatymus

Autorizacija

Keletas prisijungimo būdų: OTP per SMS, Google OAuth, Telegram WebApp su HMAC validacija (mini-apps — serveris tikrina Telegram parašą, kad įsitikintų, jog initData tikra).

Verslo metrikos ir analitika

Čia įdomiausia dalis savininkui — ką jis mato administracijoje, atidaręs ją ryte.

Daily KPIs ir Lifetime KPIs

Pirmas dalykas, kuris kraunasi administracijos pagrindiniame puslapyje — kortelės su skaičiais už šiandien: collection (pajamos), sales (pardavimai), orders (užsakymai), users (nauji vartotojai). Šalia — tos pačios metrikos už visą parduotuvės gyvavimo laiką (lifetime).

Reconciliation report

Pagrindinė finansinė ataskaita — sutikrinimas. Išdėsto pajamas pagal sudedamąsias dalis: gross revenue (bendrosios pajamos), discounts (nuolaidos), wallet used (nurašyta iš klientų piniginių), rewards used (nemokamos prekės ir bonusai), net revenue (grynosios pajamos), tax (mokestis), delivery fees (pristatymo mokesčiai), COGS (cost of goods sold — savikaina), profit margin (marža).

Atidaręs ataskaitą, savininkas mato ne „parduotuvė uždirbo X", o pilną vaizdą: kiek pinigų atėjo, kiek išėjo nuolaidoms ir dovanoms, kiek liko po mokesčių ir pirkimo.

Cash flow report

Pinigų judėjimo ataskaita. Ypač svarbi nišoje, kur daug COD užsakymų. Išskaidymas: COD pardavimai (kiek užsakymų apmokėta grynaisiais), grynieji voke pas vairuotoją (kas fiziškai surinkta), digital payments (kas praėjo per Zelle/CashApp/Venmo/kriptą), change-to-wallet (grąža, kuri nukeliavo klientui į piniginę vietoj smulkmenos), owner's cash (tai, kas galiausiai yra pas savininką).

Driver report

Už pasirinktą laikotarpį — lentelė kiekvienam vairuotojui: pristatymų skaičius, vidutinis pristatymo laikas, pajamos, grynųjų surinkta. Padeda suprasti, kas dirba efektyviai, kam reikia pagalbos, kam laikas mokėti premiją.

End-of-day report

Galutinė pamainos ataskaita. Dienos uždarymas — visi skaičiai, visi likučiai, visi neatitikimai.

COG report

Savikainos ataskaita. Pagal kiekvieną prekę — pirkimo kaina, pardavimo kaina, marža doleriais ir procentais. Padeda suprasti, kurios prekės iš tiesų neša pinigus, o kurios — parduodamos nuostolingai.

Affiliate report

Top rekomenduotojai: kas pakvietė daugiausiai klientų, kiek komisinių jiems priskaičiuota, kiek išmokėta. Galima pažiūrėti konkretų rekomenduotoją — jo rekomenduotuosius, jų užsakymus, jo piniginę.

Funnel analitika

Konversijos piltuvėliai trijose vietose:

• Registration funnel: išsiuntė OTP → įvedė kodą → užbaigė registraciją → padarė pirmą užsakymą. Kiekviename žingsnyje — perėjimo procentas ir absoliutus skaičius.
• Login funnel: panaši logika prisijungimui.
• Checkout funnel: pridėjo į krepšelį → perėjo į checkout → pasirinko adresą → pasirinko mokėjimą → paspaudė „Pateikti" → mokėjimas praėjo.

Piltuvėliai rodo, kur klientai pasitraukia. Jei 80% žmonių pasiekia mokėjimo pasirinkimą, bet tik 40% pasiekia „Pateikti" — vadinasi, šiame žingsnyje kažkas lūžta.

Conversion analytics

Atskiras ekranas — bendras piltuvėlis nuo apsilankymo iki užsakymo: Sessions → Product Views → Cart Adds → Checkout → Orders. Su procentais kiekviename žingsnyje. Tai jau ne apie konkretų klientą — tai apie bendrą parduotuvės sveikatą.

Activity Log + session replay

Neįprasčiausia analitikos dalis. Platforma fiksuoja klientų veiksmus: pridėjo prekę į krepšelį, ištrynė, pakeitė kiekį, perėjo į puslapį, išsiuntė paiešką be rezultatų, gavo klaidą, krito JS, neatvyko iki checkout dėl X priežasties.

Virš to — rrweb session replay: klientų sesijų įrašas su masked inputs (visi įvedimai maskuojami — niekas nematys, ką klientas parašė laukelyje „adresas" ar „telefono numeris"). Tik autorizuotos sesijos, ne ilgesnės nei 15 minučių per įrašą. Administracijoje galima atidaryti konkrečią sesiją ir peržiūrėti visą kliento kelią — kaip video grotuvą.

Kai klientas skundžiasi „pas jus niekas neveikė" — atsidari jo sesiją, žiūri, ką jis iš tikrųjų darė, ir per 30 sekundžių supranti priežastį.

Audit Trail

Pakeitimų žurnalas platformos administratoriui. Kas ir kada pakeitė prekės kainą, likutį, kliento piniginę. Pakeitimai dviejų sekundžių intervale grupuojami į vieną įrašą (kad neužteršti žurnalo, jei vienas redaktorius išsaugojo tris laukus iš eilės).

Issues monitor

Top dienos problemos. Dažniausios pasitraukimo iš checkout priežastys, JS klaidos klientų naršyklėse, API endpoint'ų kritimai. Padeda greitai pamatyti, kas šiuo metu lūžta.

Kas projektą daro sudėtingu iš vidaus

Iš išorės platforma atrodo kaip įprasta parduotuvė su kurjeriais. Viduje — dešimtys netrivialių užduočių, kiekviena iš kurių gali kainuoti pinigų ar klientų, jei išsprendžiama prastai.

Inventory race conditions

Scenarijus: sandėlyje viena paskutinė prekė. Du klientai vienu metu spaudžia „Pateikti". Be apsaugos — abu gaus patvirtinimą, o prekės sandėlyje nėra. Vienas klientas bus labai nusivylęs.

Sprendimas — transakcijos duomenų bazėje su sąlyga WHERE inventory >= qty. Jei pirmas klientas spėjo — antram nukris klaida dar prieš užsakymo sukūrimą, ir jis pamatys „prekė pasibaigė" vietoj patvirtinimo.

Multi-tenant izoliacija

Vienas store_id filtruoja viską: prekes, užsakymus, klientus, vairuotojus. Jei šį filtrą prarasti bent vienoje užklausoje — parduotuvė A pamatys parduotuvės B duomenis. Multi-tenant platformai tai ne tik bug'as, tai potencialios teisinės pasekmės.

Real-time tracking

WebSocket ryšys tarp vairuotojo aplikacijos ir serverio. Vairuotojas siunčia geopoziciją kas kelias sekundes. Serveris saugo paskutinę poziciją, apskaičiuoja ETA per geokodavimą ir persiunčia klientui. Jei ryšys nutrūko — reikia perjungimo be konteksto praradimo.

Compliance

Kliento KYC verifikacija registracijos metu. Asmens duomenų maskavimas screen recordings (rrweb maskAllInputs). NDA platformos lygiu. Registracija Twilio A2P, kad atitiktų amerikietiškų SMS operatorių taisykles (TCR vetting).

Pushover priority=2

Ne techninis, o operacinis dalykas. Jei naujas užsakymas nukrito į sistemą, o dispečeris to nepastebėjo — užsakymas užtrūks. Pushover su 2 prioritetu skambina telefonu garsia sirena 30 sekundžių, kol dispečeris nepatvirtina. Tai ne „patogu" — tai kritiškai svarbu, kad užsakymai neprapultų.

Cash drop reconciliation

Vairuotojai vežioja grynuosius. Pamainos pabaigoje platforma sutikrina tris skaičius: kiek tikimės pagal COD užsakymus, kiek faktiškai voke pas vairuotoją, kiek nukeliavo klientams kaip grąža formatu „padėkime skirtumą į piniginę, o ne duosime smulkmena". Jei trys skaičiai nesutampa — neatitikimas eskaluojamas savininkui.

Time slots su capacity

15 minučių laiko langai su užsakymų skaičiaus limitu. Kai limitas pasiektas — laiko langas „užgęsta" ir klientams neberodomas. Tai vairuotojų apsauga: kitaip vieną laiko langą galima perpildyti ir sugriauti visą pristatymą.

Traffic windows

Taisyklės „ZIP 33129 nepristatomas nuo 17:00 iki 19:00 darbo dienomis". Kiekvienas ZIP gali turėti savo langus. Administracijoje vadybininkas atidaro ekraną „Traffic windows" ir redaguoja — be programuotojo pagalbos.

Lokalizacija

Platforma palaiko tris lokales: anglų, rusų, ispanų. Apie 700 vertimo raktų. Visos trys turi būti palaikomos ir patikrintos — klientas Majamyje gali kalbėti bet kuria iš šių kalbų.

Santrauka

Platforma — tai ne „svetainė su krepšeliu". Tai sąsaja iš šešių vartotojų rolių, penkių sąsajų, trijų botų, šešių pristatymo zonų, šešių mokėjimo būdų ir tuzino susipynusių išlaikymo mechanikų. Kiekviena smulkmena — nuo push pranešimo prioriteto iki traffic window taisyklės — apgalvota taip, kad užsakymas neprapultų, grynieji nesusiskirstytų, o klientas grįžtų.

Projektas veikia Majamyje, aptarnauja kelias parduotuves vienoje kodo bazėje, ir kiekvienas sprendimas kode turi būti suderintas su operacine realybe: kurjeriais gatvėse, dispečeriais su garsiais telefonais, savininkais, kurie dienos pabaigoje suveda ataskaitas iki dolerio.

---

Susiję skyriai

• Admin panel — gilus pasinėrimas į administraciją: kas viduje, kaip vadybininkas dirba, kokios ataskaitos formuojamos.
• Tech stack — technologinė dalis: monorepo, NestJS, Next.js, PostgreSQL, Docker, GitHub Actions, real-time, eilės, Pushover, ir viskas, kas po variklio dangčiu.