Two systems. Two different decisions.

The system

The online ordering site for a pizza restaurant with two locations in Sofia, Bulgaria. Customers browse the menu, build a pizza with options and paid add-ons, and order for delivery or collection, as guests or from an account with order history and one-click reorder. Staff manage products, neighbourhoods, delivery rules, pages and orders in a separate admin area. A pizza place lives on dinner-time traffic. If ordering breaks on a Friday night, there is no second chance that week.

The history

The first site was written about ten years ago on a custom in-house "framework". It worked, and then it stopped being changeable. Every improvement the business asked for was either impossible or too risky to attempt. The design had aged with it.

On top of that came a hard requirement: the restaurants had moved to a new version of their till system, Mistral, with a cloud API called Zamboo. Orders from the website needed to land in it directly instead of being handled by hand.

The approach

My default is incremental modernization, and I argue against rewrites on this site. This project is the exception that shows how I decide. A custom framework nobody maintains, with no upgrade path, a redesign already on the table and a new integration that touched the core of the ordering flow: there was nothing worth preserving except the business rules.

So I preserved the business rules. Read before I change applies to a running site as much as to code. I went through the live system and wrote down how pricing actually behaved: a fixed discount for collection, a different discount per neighbourhood for delivery, a delivery fee and minimum order per neighbourhood, packaging charged per item, and items that were already on offer excluded from any further discount. Those rules went into the new system unchanged. Everything around them was built fresh.

What was built

• Symfony 7.4, PHP 8.4, Doctrine ORM 3 on PostgreSQL. Attribute routing, constructor injection, Symfony Security with separate firewalls for customers and staff, Symfony Forms for the whole admin.
• A redesigned, responsive front end in Bulgarian: menu by category, product pages with options and add-ons, allergens, lunch menu, restaurant pages with maps, editable content pages and a site-wide announcement banner staff can switch on from the admin.
• The cart rewritten in Vue 3. The old cart was the part nobody could touch, because every rule interacted with every other rule. The new one is a single Vue component, built with Vite into one file and mounted inside the Twig page. It talks to small JSON endpoints, keeps the server-side session cart as the source of truth, and recalculates totals live as the customer switches between collection and delivery or changes neighbourhood. The server recomputes everything again at checkout. The browser is for display, never for trust.
• Dual currency. Bulgaria adopted the euro in January 2026. Every price shows in euro and leva at the fixed rate, in the cart, on the product pages and in the admin.
• Mistral via Zamboo. Each product carries its Mistral id, and an admin page lists the till's own catalogue so the two can be matched without guessing. When an order comes in, the admin order screen picks it up without a reload. One click translates it into the till's format: every product line by Mistral id, the chosen options as text, add-ons, packaging lines, the delivery fee, and the discount as a negative line, with the address, phone and comment attached. It is posted to the restaurant's own endpoint, and the order is marked completed and assigned to that restaurant. The kitchen gets the ticket. Nobody retypes anything.

Results

The business rules that made the old site valuable are still there. Everything that made it untouchable is gone. Since launch the site has taken a steady stream of improvements, including the euro changeover and a new discount model, each one a small change instead of a project.