LilyByte

FastFood

Design di prodottoSviluppo frontendBackend e APIDati e geospazialeAuth e sicurezzaDevOps (previsto)

FastFood è una piattaforma completa per ordinare cibo, costruita attorno a due esperienze collegate. Un'app web per il cliente permette di scoprire i ristoranti vicini, sfogliare i menu con dettagli e allergeni dei piatti, comporre un ordine in un carrello vivo e concludere scegliendo il metodo di pagamento, e poi di seguire l'ordine lungo tutto il suo percorso, in tempo reale. Una console di gestione permette al ristoratore di curare il menu, far avanzare gli ordini in arrivo lungo la loro filiera di stati e seguire l'andamento su un cruscotto di analisi. LilyByte ha progettato e costruito l'intero prodotto da capo a fondo (frontend Next.js, API Express/MongoDB) come progetto proprio.

I due ruoli sono mossi da un sistema solo: un unico modello di account con un interruttore cliente/ristorante, un ordine solo che entrambe le parti vedono e su cui possono agire, e un motore di scoperta consapevole della posizione che lega i menu a una mappa.

La sfida

Un mercato per ordinare cibo è in realtà due prodotti che devono darsi ragione a vicenda. Costruirli bene entrambi, insieme, era la sfida centrale.

Due pubblici, un solo modello dati. Il cliente vuole velocità: trovare qualcosa di buono lì vicino e ordinarlo in pochi tocchi. Il ristorante vuole controllo e visione: gestire il menu, lavorare gli ordini in arrivo, capire come va. Entrambi sono mossi dagli stessi ristoranti, menu e ordini.

Scoperta consapevole della posizione. La scoperta funziona solo se rispetta dove sei e cosa ti piace: interrogazioni geospaziali vere per i ristoranti vicini a un indirizzo, insieme alle preferenze di cucina e ai vincoli sugli allergeni.

Un ciclo dell'ordine condiviso e dal vivo. Un ordine attraversa gli stati ordinato, in preparazione, pronto o in consegna, e completato. Lo stesso dato alimenta la finestra di tracciamento del cliente e la bacheca operativa del ristorante, quindi lo stato deve restare coerente su entrambi i lati.

Un imbuto d'ordine completo. Dal piatto sfogliato alla sua scheda, poi al carrello vivo, poi alla conferma con dettagli e metodo di pagamento: tutto il percorso doveva sembrare una vera app per ordinare, non un modulo da riempire.

Visione operativa. Al ristoratore servivano analisi vere (andamento di incassi e ordini, piatti che vendono di più e di meno, confronti fra periodi) presentate con chiarezza.

La soluzione

FastFood unisce un frontend Next.js moderno a un backend geospaziale Express/MongoDB, tenuti insieme da uno strato di autenticazione consapevole dei ruoli.

001

Un frontend Next.js consapevole dei ruoli

Il client è costruito su Next.js 15 (App Router, Turbopack) con il sistema di componenti HeroUI e Tailwind CSS. I gruppi di rotte separano l'app del cliente dalla console del ristorante, e una guardia di autenticazione porta ogni utente sulla superficie giusta. Chart.js muove le analisi, e lo stato di carrello e ordine è tenuto con il context di React, così il flusso sopravvive a tutto il percorso di acquisto.

002

Un'API geospaziale per gli ordini

Il backend è un'API REST Express 5 su MongoDB via Mongoose, protetta con JWT (bcrypt), validata con Joi, documentata con Swagger, e con le immagini dei menu gestite da Multer. La scoperta si appoggia agli indici 2dsphere di MongoDB e a pipeline $geoNear che ordinano i ristoranti per distanza e filtrano i piatti per cucina e allergeni; Nominatim di OpenStreetMap geocodifica gli indirizzi e OSRM stima i tempi di consegna.

003

Un ciclo dell'ordine, due viste

Una sola collezione di ordini è la spina dorsale dell'app: alimenta la finestra di stato dal vivo del cliente, la bacheca di gestione del ristorante e le aggregazioni del cruscotto per incassi, numero di ordini, andamento delle vendite e popolarità dei prodotti.

Funzioni chiave

Autenticazione e ruoli

Un'unica registrazione con un interruttore Utente/Ristorante porta ogni persona sull'esperienza giusta; le sessioni usano JWT.

Scoperta e ricerca

La home è personalizzata per gusto e posizione; una pagina di ricerca dedicata aggiunge un carosello di categorie, preferenze di cucina, esclusione degli allergeni e un filtro «aperto ora» sopra l'ordinamento geospaziale.

Il percorso d'ordine

Il cuore dell'app cliente è un imbuto d'ordine completo. Dalla pagina di un ristorante, un piatto apre una scheda con foto, etichette, allergeni e ingredienti; aggiungendo piatti si riempie un carrello vivo con quantità e totale corrente; e la conferma raccoglie i dettagli dell'ordine e il metodo di pagamento prima dell'invio.

Tracciamento dell'ordine

Il cliente segue ogni ordine lungo il suo percorso in una finestra di stato in tempo reale (da «In attesa di conferma» a «In preparazione», «Pronto per il ritiro» e «Completato») con l'ordine dettagliato e l'avanzamento. Il ristorante fa avanzare lo stesso ordine dalla sua console.

Area cliente

Il cliente gestisce profilo, indirizzi di consegna e carte salvate da un'area dedicata.

Console ristorante: cruscotto di analisi

Il cruscotto del gestore trasforma il flusso degli ordini in visione: schede di indicatori per ordini e incassi (oggi, settimana, mese, con scarti sul periodo precedente e scontrino medio), un grafico configurabile dell'andamento delle vendite, una tabella dei piatti più e meno venduti e un flusso dal vivo degli ordini recenti.

Console ristorante: menu e ordini

Il ristoratore cura il catalogo con la gestione completa dei piatti (aggiungendone uno nuovo o scegliendone uno esistente) e lavora gli ordini in arrivo su una bacheca ricercabile e paginata, facendo avanzare lo stato di ciascuno da una finestra.

Tecnologie

001

Frontend

  • Next.js 15: App Router with Turbopack; role-based route groups and an auth guard
  • React 18 + TypeScript
  • HeroUI component system + Tailwind CSS for a consistent, responsive design
  • Chart.js analytics · Framer Motion · react-beautiful-dnd · Axios · js-cookie
  • React context for cart & auth state that persists across the ordering flow

002

Backend e API

  • Node.js with Express 5: REST API
  • MongoDB with Mongoose ODM
  • JWT authentication with bcrypt-hashed credentials; role-based access
  • Joi validation · Multer image uploads · Swagger (OpenAPI) docs

003

Geospaziale e dati

  • MongoDB 2dsphere indexes and $geoNear aggregation for “near me” discovery
  • Preference- and allergen-aware feeds and search via aggregation pipelines
  • OpenStreetMap Nominatim geocoding + OSRM routing for delivery-time estimates
  • Server-side analytics aggregations for revenue, orders and product trends

Aree di lavoro

Il lavoro ha coperto l'intero ciclo di vita del prodotto, su questi fronti:

001

Design di prodottoflussi e interfaccia per due ruoli sotto un solo sistema di design.

002

Sviluppo frontendclient Next.js, percorso d'ordine con stato e visualizzazione dei dati.

003

Backend e APIservizi REST in Express, validazione e documentazione.

004

Dati e geospazialeschema MongoDB, indici 2dsphere e aggregazioni.

005

Auth e sicurezzasessioni JWT, hashing delle password e instradamento per ruolo.

006

DevOps e rilasciopiano di messa in produzione (qui sotto).

Produzione e scala (previste)

FastFood è un prototipo completo di funzioni che non è ancora stato pubblicato. Qui sotto la strada prevista verso la produzione e gli obiettivi che le sono stati posti.

001

Architettura di rilascio

Il frontend andrebbe su Vercel con cache al bordo e ottimizzazione delle immagini, mentre l'API Express girerebbe come servizio containerizzato (Render / Fly.io / AWS ECS) dietro un bilanciatore. I dati passerebbero su MongoDB Atlas conservando gli indici geospaziali, con backup automatici; le immagini dei menu sarebbero servite da archiviazione a oggetti (S3) tramite una CDN (CloudFront) invece che dalla cartella locale. Una pipeline GitHub Actions si occuperebbe di CI/CD, e l'impianto sarebbe strumentato con log strutturati, tracciamento degli errori (Sentry) e monitoraggio della disponibilità.

002

Irrobustimento per il traffico vero

Prima del lancio la piattaforma aggiungerebbe limitazione delle richieste e sanificazione degli input al bordo dell'API, cookie di sessione sicuri e non leggibili da JavaScript, moderazione delle immagini caricate, una conferma d'ordine idempotente appoggiata a un vero fornitore di pagamenti (Stripe) e notifiche push ed email sui cambi di stato. Una cache Redis starebbe davanti alle interrogazioni di scoperta più frequenti, e la filiera degli ordini passerebbe ai websocket per aggiornamenti davvero dal vivo su entrambi i lati.

Obiettivi attesi

Gli obiettivi della messa in produzione sono stati posti come traguardi concreti, non come risultati misurati:

~50

Ristoranti al lancio

Portare a bordo un primo gruppo di circa 50 ristoranti partner in una sola città, al lancio.

<300ms

Risposta della ricerca geospaziale

Tempo di risposta mediano sotto i 300 ms per le interrogazioni di scoperta geospaziale a carico nominale.

100s

Sessioni contemporanee per istanza

Reggere centinaia di sessioni d'ordine contemporanee su una sola istanza dell'API, prima di crescere in orizzontale.

99.9%

Disponibilità, con ripristino automatico

99,9% di disponibilità attesa, con backup automatici e ritorno indietro in un clic.

<24h

Dalla registrazione al primo ordine

Imbuto del ristoratore: dalla registrazione al primo menu pubblicato al primo ordine lavorato in meno di un giorno.

Nota: questo progetto non è stato pubblicato in produzione; l'architettura di rilascio e i numeri di questa sezione sono l'impianto previsto e gli obiettivi posti, non risultati misurati.

LilyByte

Costruiamo il prodotto. Tu costruisci il business.

L'idea la porti tu. Noi mettiamo team, processo ed esperienza per realizzarla.

Email

info@lilybyte.com

Telefono

+393514397419

Social

Instagram

LinkedIn

Note legali e privacy

©2026. Tutti i diritti riservati