/ Case study — Landing
Ayam Bakar Asap Jimbaran
Now the restaurant runs its own storefront. Staff change the menu, catering, promos, even the look of the page — all from one admin, without waiting on a developer.
Pesanan
Kelola & perbarui status pesanan secara real-time.
| Order | Pelanggan | Item | Mode | Total | Waktu | Status |
|---|---|---|---|---|---|---|
| ABJ-1042 | Sophia Laurent | Ayam Bakar Dada · 2x | Antar | Rp82.000 | 16 Jul, 14:22 | Disiapkan |
| ABJ-1041 | Rizky Pratama | Paket Komplit · 2x | Ambil | Rp90.000 | 16 Jul, 14:08 | Siap |
| ABJ-1040 | PT Sinar Mas | Paket Komplit · 120x | Reservasi | Rp5.400.000 | 16 Jul, 13:51 | Dibayar |
| ABJ-1039 | Dewi Anggraini | Sate Lilit (5 Tusuk) · 3x | Antar | Rp87.000 | 16 Jul, 13:30 | Diantar |
| ABJ-1038 | Bagus Wirawan | Ayam Bakar Madu · 1x | Ambil | Rp35.000 | 16 Jul, 13:02 | Selesai |
One backend, every channel — delivery, pickup and catering land on the same board.
The actual back office — delivery, POS and catering orders on one lifecycle.
ayambakarasapjimbaran.co.idFIG.00 — Overview- Content-as-data — menu/catering/appearance, no deploy
- One backend feeds storefront + delivery + POS
- Drizzle → Turso (edge) · server-side price rules
/ What it does
Run your whole business from one simple dashboard
Menu, prices, promos, even how the storefront looks — all editable from one admin, no developer needed. Change it once, and it updates everywhere: the website, the delivery app, and the till.
Open the admin
One dashboard for everything.
No developer needed
Your team changes the menu and prices themselves, anytime.
One place, everywhere
Edit once — the website, app, and till all stay in sync.
Reach customers everywhere
Your own storefront plus GoFood and GrabFood, from one system.
Problem
A restaurant brand outgrows a brochure site the moment its menu changes weekly, catering packages come and go, promos rotate, and orders arrive across three channels. Editing any of that shouldn’t require a developer or a redeploy.
Approach
Build the brand site as the front of a small commerce platform. One typed backend on an edge database is the single source of truth for menu, catering, combos, banners — even the storefront’s appearance — and an authenticated admin lets staff change all of it live.
- Next.js app rendering the public brand and the authenticated admin from one codebase.
- Content — menu, catering packages, combos, banners, appearance — lives in the database, editable without a deploy.
- Ordering fans out to the brand’s own flow plus GoFood and GrabFood, meeting customers where they already are.
A brand site is a read view of a business. Model the business, and the site edits itself.
Architecture
Next.js (brand storefront + admin)
├─ public: menu · catering · combos · banners ── read from SSOT
├─ admin: appearance · pricing · promos ── auth-gated writes
└─ data: Drizzle ORM → Turso (libSQL, edge)
Ordering → direct flow · GoFood · GrabFoodKey decisions & trade-offs
- Content as data, not markup. Menu, catering, and even the storefront’s look live in the DB so non-engineers run the business day to day.
- One backend, many faces. The same source of truth feeds the brand site, the delivery storefront, and the POS — no duplicated product catalogs to drift apart.
- Meet customers where they order. Rather than fight the aggregators, the platform routes cleanly to GoFood/GrabFood alongside the brand’s own channel.
Result
A restaurant that runs its own commerce — menu, catering, promos, and storefront appearance — from a single admin, on a backend shared with delivery and point-of-sale.
Masalah
Sebuah brand restoran melampaui situs brosur begitu menunya berubah tiap minggu, paket catering datang dan pergi, promo bergilir, dan pesanan tiba lewat tiga channel. Mengedit semua itu semestinya tidak butuh developer atau redeploy.
Pendekatan
Bangun situs brand sebagai muka dari sebuah platform commerce kecil. Satu backend ber-type di atas basis data edge jadi satu-satunya sumber kebenaran untuk menu, catering, combo, banner — bahkan tampilan storefront-nya — dan sebuah admin terautentikasi membiarkan staf mengubah semuanya secara langsung.
- Aplikasi Next.js merender brand publik dan admin terautentikasi dari satu basis kode.
- Konten — menu, paket catering, combo, banner, tampilan — hidup di basis data, bisa diedit tanpa deploy.
- Pemesanan menyebar ke alur milik brand sendiri plus GoFood dan GrabFood, menemui pelanggan di tempat mereka sudah berada.
Situs brand adalah tampilan-baca dari sebuah bisnis. Modelkan bisnisnya, dan situsnya mengedit dirinya sendiri.
Arsitektur
Next.js (brand storefront + admin)
├─ public: menu · catering · combos · banners ── read from SSOT
├─ admin: appearance · pricing · promos ── auth-gated writes
└─ data: Drizzle ORM → Turso (libSQL, edge)
Ordering → direct flow · GoFood · GrabFoodKeputusan kunci & trade-off
- Konten sebagai data, bukan markup. Menu, catering, dan bahkan tampilan storefront hidup di DB jadi non-engineer menjalankan bisnis sehari-hari.
- Satu backend, banyak wajah. Sumber kebenaran yang sama menyuapi situs brand, storefront delivery, dan POS — tanpa katalog produk ganda yang bisa melenceng.
- Temui pelanggan di tempat mereka memesan. Alih-alih melawan aggregator, platformnya mengarahkan dengan rapi ke GoFood/GrabFood berdampingan dengan channel milik brand sendiri.
Hasil
Sebuah restoran yang menjalankan commerce-nya sendiri — menu, catering, promo, dan tampilan storefront — dari satu admin, di atas backend yang dibagi dengan delivery dan point-of-sale.
/ How it’s done
Content as data — live
Edit the menu item; the storefront reflects it instantly. Menu, promos, even appearance are data in one backend — no deploy.
Content is data, not markup. Non-engineers run the storefront — menu, catering, promos, even its appearance — because it all lives in one typed backend. The same source of truth feeds delivery and POS, and prices are recomputed server-side before any invoice.
Content is data, not markup
Menu, catering, combos, banners and the storefront’s look live in the DB. Staff run the business day to day — no developer, no redeploy.
Menu, catering, combo, banner, dan tampilan storefront hidup di DB. Staf menjalankan bisnis sehari-hari — tanpa developer, tanpa redeploy.
One backend, many faces
The same typed SSOT feeds the brand storefront, the delivery app, and the POS — no duplicated product catalogs to drift apart.
SSOT ber-type yang sama menyuapi storefront brand, aplikasi delivery, dan POS — tanpa katalog produk ganda yang bisa melenceng satu sama lain.
Pricing where it can be trusted
Prices and promos are recomputed server-side before any invoice; the client never quotes a total it can be trusted on.
Harga dan promo dihitung ulang di sisi server sebelum ada invoice; klien tidak pernah mengutip total yang bisa dipercaya begitu saja.
Edge data, Next.js front
Drizzle on Turso (edge libSQL) behind a Next.js app that renders the public brand and the authenticated admin from one codebase.
Drizzle di atas Turso (libSQL edge) di belakang aplikasi Next.js yang merender brand publik dan admin terautentikasi dari satu basis kode.