Piazza Napoletana

Piazza Napoletana is a reservation website and admin dashboard built for a working Italian restaurant in Gommern-Menz, Germany. The whole design brief was one sentence: a guest should be able to book a table in under thirty seconds, on a phone, in German.

Context and problem. Restaurant booking widgets usually fail in one of two directions. Either they are a plain contact form, which means the owner reconciles requests by hand and guests never know if a time is actually free; or they are a heavy third-party platform with per-cover fees and someone else's branding. The real constraint is that availability is not a fixed list of slots — it is derived from the restaurant's opening hours and its remaining capacity, and both change. Hard-coding time slots guarantees the site drifts out of sync with the business the first time the owner changes a closing day.

Solution. The reservation flow is a four-step wizard — guests, then date, then time, then contact details — where each step narrows the next. Time slots are not stored; they are generated on request from the opening hours held in the database and then filtered by remaining capacity for that date, so a slot that is full simply does not appear. The owner edits opening hours, the profile, and the hero image from a password-protected admin dashboard, which also lists reservations by date with status changes and deletion — no developer involvement for day-to-day operation. Production runs on Turso (libSQL) with images in Vercel Blob, but with no tokens configured the app falls back to a local SQLite file and local uploads, so a fresh clone runs immediately with npm run dev.

Engineering and quality focus. Deriving availability from stored opening hours rather than a slot table is the decision the rest of the correctness rests on: there is exactly one source of truth, and the owner changing Monday's hours updates the booking form with no deploy. Inbound payloads are validated with Zod at the route-handler boundary, and the admin surface is gated by a password login plus a signed session token from an environment secret rather than a client-side flag. The zero-configuration fallback path is deliberate quality work too — it means the project can be cloned, reviewed, and demoed by anyone without provisioning a database, which is exactly what a handover to a client requires.