Bulgogi Bowl · telur ½
Rp 38.000
Il cliente si è rivolto a noi prima dell'apertura — stava pianificando una ghost kitchen a cinque brand che girava su un'unica linea di preparazione, e cercava un sistema in grado di reggere fin dal lancio. Il brief era chiaro: ogni brand doveva sembrare un negozio a sé per il cliente, ma la cucina, l'admin e la contabilità dovevano funzionare come un'unica operazione. Abbiamo costruito l'intero stack su quella base, pronto il giorno dell'apertura.
Ogni brand ha la sua pagina catalogo, il suo colore, il suo tracker di stato, il suo feed stile Instagram. Per il cliente sembra un negozio specializzato. Dietro le quinte c'è un unico database, un unico pannello cucina e un unico registro finanziario — taggati per brand a ogni riga, così i conti saranno corretti fin dalla prima chiusura mensile.
Menu a feed Instagram per ogni brand — post a carosello, doppio tap, stepper aggiungi al carrello, campo note. Ogni brand ha il suo URL, la sua palette e il suo tono di voce. Il cliente tocca il link in bio su Instagram o TikTok del brand, atterra sulla sua vetrina e vede un solo negozio, non cinque.
La geolocalizzazione in tempo reale calcola la tariffa di consegna rispetto al pin della cucina prima che il cliente confermi. Paga in contanti, con QRIS o bonifico. L'ordine arriva in cucina nel momento in cui il QRIS viene confermato.
Un solo schermo sulla linea di preparazione. Ogni ordine in coda, con bordo colorato per brand. Le stazioni scorrono da in coda → in cottura → pronto. Contatori in tempo reale in cima. Nessun ticket cartaceo, nessun ordine perso.
Cinque fasi — ricevuto, pagato, in cottura, in consegna, arrivato. Il cliente vede il brand da cui ha ordinato, non "ghost kitchen." Aggiornamento automatico dai tap sul pannello cucina. L'URL di stato rimane nel browser così il cliente può riaprirlo invece di chiamare.
Il pannello del titolare. Filtra per brand, per fase, per data. Vedi gli ordini attivi, il conteggio di oggi, lo storico, la divisione del fatturato brand per brand. Una sola schermata per gestire tutti e cinque i brand — senza cambiare app.
Tracciamento del fatturato per brand con ripartizione dei costi condivisi (affitto, personale, gas, imballaggi). P&L mensile per brand calcolato in automatico. Tracker del budget marketing così sappiamo il costo per cliente per brand — l'unico numero che decide cosa lanciamo dopo.
Cinque brand, una sola linea di preparazione. Due attivi il giorno dell'apertura; tre pre-cablati nel database.
Il cliente voleva lanciare con due brand e avere altri tre pre-cablati nel database per dopo. Ogni brand aveva il suo posizionamento, la sua palette e il suo pubblico — un cliente che ordina una rice bowl coreana non dovrebbe mai sapere che la stessa cucina spedisce anche geprek. La vetrina per il cliente doveva leggere come un brand unico e riconoscibile fin dal primo tap.
Ma costruire cinque volte la stessa cosa non era un'opzione. Serviva un'unica shell che indossasse cinque facce — semplice da lanciare un nuovo brand in un giorno, non in uno sprint.
Una singola shell PWA fa il render della vetrina. Uno slug brand nell'URL carica i token di colore, la tipografia, i prodotti e il copy giusti all'avvio — stesso codice, negozio diverso. Il cliente tocca il link in bio Instagram o TikTok del brand, atterra sulla sua vetrina dedicata, e non vede mai gli altri.
Attivare un nuovo brand per il cliente è ora una riga nel database, un colore e una lista prodotti. Geprek 28 e Sego Sambel sono andati live nella settimana 2; Bap Bowl, Nasgor Mas e Tumis Bunda sono pre-cablati, pronti quando il cliente decide di attivarli.
Il rischio segnalato dai fondatori fin dall'inizio: con un solo team di preparazione che gestisce cinque brand, il contesto del brand svanisce tra l'ordine e il piatto. Un ticket "nasi + sambal + ayam" potrebbe appartenere a Geprek 28, Sego Sambel o Nasgor Mas — e una scatola con il brand sbagliato consegnata a un cliente nella settimana del lancio sarebbe molto pubblica, molto veloce.
La schermata cucina doveva rendere il brand impossibile da ignorare, anche al picco del servizio, anche nel primo turno che il team abbia mai fatto.
Ogni ticket sullo schermo cucina porta una barra sinistra colorata — un colore per brand. Il nome del brand campeggia in alto in mono grassetto. Non esiste scenario in cui il cuoco legge un ticket senza sapere di chi è l'ordine.
Tap per avanzare: antri → masak → siap. Il tracker di stato del cliente si aggiorna all'istante. Il chip nella coda brand dell'admin scende di uno. Un tablet, tre swipe, nessun secondo schermo da tenere sincronizzato — pronto per essere imparato dal personale in un pomeriggio.
Cucina condivisa, personale condiviso, gas condiviso, fornitore di imballaggi condiviso. Il fatturato per brand è banale — sommi le ricevute. Il profitto per brand è il numero più difficile. I fondatori volevano vederlo dal primo mese, non dopo un anno di supposizioni.
Il punto: la decisione "lanciamo il quarto brand?" doveva basarsi su un numero, non su una sensazione. Il che significava costruire la ripartizione dei costi condivisi nel sistema prima ancora che arrivasse il primo ordine.
Ogni ordine, ticket, riga di stato e voce di registro porta il brand_id dal momento in cui viene scritto. I costi condivisi (affitto, gas, personale base) si ripartiscono automaticamente in base alla quota ordini di ogni brand in quel mese. I costi specifici per brand (SKU imballaggi, ingredienti taggati a un brand) colpiscono direttamente il registro corretto.
La spesa marketing è collegata a un brand e a una campagna — il costo per cliente si calcola da solo dal registro ordini. Il pannello admin brand-aware dà al titolare un'unica schermata per leggere tutti e sei.
Non abbiamo iniziato dal database. Abbiamo iniziato con una pagina catalogo simulata per uno dei brand di lancio, su un telefono, e l'abbiamo messa davanti ai fondatori — un cliente ci crederebbe? Una volta che ha funzionato, abbiamo lavorato a ritroso verso la cucina e l'admin.
Questo è quello che i fondatori trovano il giorno dell'apertura. I numeri operativi live (CAC, margine per brand, throughput) arrivano una volta che la cucina è in funzione — li pubblicheremo quando ci sono dati reali alle spalle.
La vetrina cliente è una singola PWA. Uno slug brand nell'URL carica i token del tema (colori, tipografia, copy), la lista prodotti e la destinazione ordine all'avvio. Nuovo brand = nuova riga nella tabella brands, nuova lista prodotti, si spedisce.
Ospitato sullo stesso setup XAMPP che il titolare usa già per il resto dell'operazione. Nessun build step, nessun Docker, nessuna reinvenzione. Leggibile dal cugino, di proposito — lo schermo cucina deve continuare a funzionare quando lo sviluppatore dorme.
Ogni ordine, ticket, riga di stato e voce di registro porta il brand_id. La cucina filtra per brand_id, l'admin filtra per brand_id, la finance alloca per brand_id. Non esiste posto nel sistema dove una riga esiste senza sapere a quale brand appartiene.
Il cliente arriva dal link in bio Instagram o TikTok del brand, apre una PWA, ordina, paga con QRIS, segue l'URL di stato. Nessun app store, nessun login. Il social del brand fa il lavoro di marketing; la vetrina deve solo convertire.
Un tablet Android a parete sulla linea di preparazione. I ticket arrivano in streaming, con bordo colorato. Tap per avanzare attraverso tre stati. Contatori live in cima così il cuoco conosce la profondità della coda senza aprire nulla.
Affitto, gas e costo del personale base vengono suddivisi ogni mese in base alla quota ordini di ogni brand sul totale. I costi specifici per brand (SKU imballaggi, ingredienti taggati a un singolo brand) colpiscono direttamente il registro corretto. Formula leggibile dal titolare visibile riga per riga.
Chiamata di analisi gratuita. L'abbiamo fatto per noi stessi — sappiamo cosa morde al secondo mese.