Pickup days follow lead time
Each product has a lead time. The earliest day follows the product in the cart that takes longest.
Patisserie website and preorder system
ZUKA Berlin
A German-language patisserie website with a product catalogue and a preorder system that computes valid pickup days and times from each product's lead time, plus a custom admin for the shop team.
Screens
Homepage
The first viewport: the patisserie's promise, a purple glazed tart, and one clear action to preorder.
How ordering works
Three steps, no phone call: choose, pick a day the shop can actually deliver, collect at the café.
Dessert catalogue
Nine tarts, each with its price and lead time, and a flag on those that can be ordered directly.
Product page
Price, lead time, ingredients and allergens on one page, with a quantity limit per order.
Cart
The summary states how the earliest pickup day is derived from the lead times in the cart.
Pickup slots
The earliest valid day is flagged, later days follow, and half-hour times appear for the chosen day.
Cake request
Custom cakes start as a non-binding request: choose a type, add details and contact data, review, send.
On the phone
The same journey on a phone: homepage, two-column catalogue and product page.
System
Features
Only workable slots are offered
Days and half-hour times are computed from the opening days.
Weekend-only range
The Wochenend-Früchte are collected on Friday, Saturday or Sunday and reservable from Wednesday.
Cake request in four steps
Choose, describe, add contact data, review. The request is non-binding.
Accept or reject with e-mail
Staff decide on each order and the customer is informed by e-mail automatically.
Invoice PDFs from the admin
The admin produces invoice PDFs for orders.
Decisions and tradeoffs
Decisions we made
Lead time decides the calendar, not the customer
Decision
Every product carries its own lead time, and the server computes which pickup days and half-hour times are possible from the longest lead time in the cart and the opening days.
Why we made it
The customer only sees slots the shop can honour, so an impossible request cannot be submitted. The cost is that the rules live in one server-side engine that must stay correct, which was accepted because the alternative was the manual back-and-forth the project set out to remove.
A custom admin over the stock CMS screens
Decision
Payload CMS 3 provides the data model, the API and the admin foundation, but the admin the shop team uses is custom-designed for orders, products, opening hours and invoices.
Why we made it
The stock screens are generic, so the admin was designed around the tasks the shop team actually performs: handling orders, maintaining products, setting opening hours and issuing invoices. The tradeoff is more interface code to maintain than a stock admin, in exchange for a tool that fits the work and runs on a phone, tablet or laptop.
Money in integer cents, orders frozen at submission
Decision
All amounts are handled as integer cents, which removes floating-point rounding from prices and totals.
Why we made it
When an order is submitted it is stored as a frozen snapshot of what was ordered, so later changes to the catalogue do not rewrite an order that already exists. The tradeoff is that an order carries a copy of the data instead of references to live products, which is the point: the order stays what the customer saw.
Next
Contact
Let's talk.
For professional opportunities, collaborations, or selected freelance work.
Open to conversations Frankfurt, Germany Europe/Berlin
GitHub penguindevteam@gmail.com