Building an Order System for an Italian Butcher Shop

Why I Built This

Mazzucchi, a small butcher shop in Italy, managed orders through phone calls and handwritten notes. Customers would call in their requests for specific cuts and weights, and the owner would jot them down on a notepad.

This process had recurring problems:

• Miscommunication of cut names or weights during phone orders
• Missed orders during peak hours when the phone couldn't be answered
• Reviewing sales meant flipping through receipts one by one

To solve these problems, I built a customer-facing mobile web app and a dedicated admin app.

What I Built

Customer Mobile Web

Customers browse the product catalog on their smartphone browser, select cuts and weights, then book a pickup date and time slot. No app installation required.

Admin App (Android / Web)

The shop owner uses the admin app for:

• Order management: Review incoming orders, update status (Pending, Processing, Ready, Completed)
• Weight confirmation: If a customer ordered 500g but the actual weight is 520g, the owner enters the measured value to finalize the price
• Product & category management: Register products by cut, update prices, soft-delete discontinued items
• Sales analytics: Daily/monthly/yearly revenue trends, category breakdowns, top products
• FCM push notifications: Automatic alerts to customers when order status changes

Tech Stack & Architecture

| Layer | Technology | |---|---| | Frontend | Flutter (Web + Android), BLoC pattern | | Backend | Kotlin, Ktor, Exposed ORM | | Database | PostgreSQL | | Infrastructure | Docker Compose, Nginx, Let's Encrypt | | Monitoring | Grafana + Prometheus | | Push Notifications | Firebase Cloud Messaging | | Server | Hetzner CX22 (Nuremberg), Ubuntu 24.04 |

While the app currently targets Italian only, the database schema separates translations into dedicated tables (ProductTranslations, CategoryTranslations), making future multi-language support straightforward.

Technical Challenges

1. Soft Delete & FK Integrity

Deleting a product shouldn't erase it from historical orders. Hard deletes violate Foreign Key constraints, so I implemented a soft-delete pattern using an is_deleted flag.

• Deleted products are hidden from listings but appear with a "(deleted)" suffix in past orders
• New orders referencing deleted products are blocked server-side
• Categories follow the same pattern since products reference them via FK

2. Weight Finalization Flow

A domain-specific requirement: the customer's requested weight and the actual measured weight often differ. I designed a finalize API to handle this:

• Customer orders: "500g beef tenderloin, 2 packs"
• Owner confirms: enters actual measured weight of 520g, price recalculated
• Status transitions to COMPLETED, FCM notification sent to customer

3. Date-Based Order Query Optimization

Orders have both a scheduled date (scheduledAt) and a completion date (completedAt). When querying orders for a specific date, completed orders filter by completion date while pending orders filter by scheduled date.

4. Caching Strategy

Product and category data is loaded into an in-memory cache at server startup to avoid repetitive JOINs on every order query. The cache is refreshed whenever products or categories are created, updated, or deleted.

Deployment & Operations

The entire stack runs on a Hetzner VPS at 5 euros per month via Docker Compose. Nginx handles reverse proxying and SSL termination with free Let's Encrypt certificates.

Deployment uses an rsync-based script. Docker multi-stage builds separate the dependency layer from the source layer, so builds are fast when only source code changes.

Reflections

Building for a real user revealed many domain-specific complexities I hadn't anticipated: the weight finalization flow, cascading effects of soft deletes, and the nuances of date-based queries.

This project taught me that building something that "works" is far easier than building something that "doesn't break."