A ground-up rebuild of SafestMenu, our restaurant menu platform, with no downtime

The challenge

A restaurant menu changes constantly. Prices move, dishes sell out, and seasonal items arrive and leave. Most restaurants still treat the menu as a print product. Reprint cycles and designer hours then sit between the kitchen and the guest. SafestMenu, our own product, removes that delay. An owner builds a branded digital menu in a drag-and-drop editor and publishes it behind a QR code that never changes. The owner updates a price or hides a sold-out dish in seconds. An owner is rarely a copywriter or a photographer, so the editor includes AI: dish descriptions, ingredient lists, and food photography.

By 2026 we faced a third, self-inflicted challenge. The product ran reliably from 2020, but we no longer wanted to add new features to its base. It also had effectively no automated tests. Many businesses know this situation: software that works, but that blocks the future. Our answer was a ground-up rebuild, with no downtime and no change to a single customer record.

What we built

For a restaurant, SafestMenu covers the whole menu workflow:

• menus with categories and products, prices, allergens, and markers for spiciness and vegetarian dishes
• style control down to the colors, the fonts, the currency, and the tone of voice
• a mobile menu that a guest opens with the QR code
• all of it in six languages

A free plan with one menu and five products serves an independent restaurant. Paid subscription plans serve small chains. The AI features run on a simple token system. A text generation costs one token and a photo costs five. Every account starts with 100 free tokens, and a subscription adds more.

The product now exists two times: the original version from 2020, and a complete rebuild on a modern base. Both generations together hold roughly 49,000 lines of code. One rule defines the rebuild: the new system reads the same data as the old one. There is no risky data migration. Every existing customer logs in with the usual password, and every menu and photo stays exactly in place. The switchover is a single setting. If anything looks wrong, we set it back.

How we built it

We rebuilt the product feature by feature against the live original, under written guardrails. A migration plan of 1,355 lines records a decision for each bug: a fix, or an exact copy of the old behavior. Customers often depend on a quirk. A tracker lists every feature of the old product and the match status of the new one. We checked each entry against a live copy of the system, not on paper.

The safety net is the tests. The original had effectively none. The rebuild has 1,106 automated tests, under a standing rule of at least ninety percent code coverage. Even a detail such as photo processing reproduces the old behavior precisely. A check finds any missing image and generates it again before the switchover. An AI photo request passes a moderation step first.

What this build demonstrates

SafestMenu is where we prove the discipline we sell. The rebuild matches the old product feature for feature. The remaining steps before the switchover are final preparations and manual checks, not new code. The pattern is clear: rebuild the application, leave the data in place, reproduce the old behavior down to its quirks, and prove everything with tests. We bring that pattern to a client whose system outgrew its base, and who cannot afford a loss of data, users, or uptime.