Rebuilding SafestMenu, our restaurant menu platform, from the ground up - without taking it offline

The challenge

A restaurant menu changes constantly - prices move, dishes sell out, seasonal items come and go - yet most restaurants still treat it like a print product, with reprint cycles and designer hours standing between the kitchen and the guest. SafestMenu, our own product, removes that lag. Owners build a branded digital menu in a drag-and-drop editor, publish it behind a QR code that never changes, and update a price or hide a sold-out dish in seconds. Because owners are rarely copywriters or photographers, AI is built into the editor: generated dish descriptions, ingredient lists, and food photography.

By 2026 we faced a third, self-inflicted challenge. The product had run reliably since 2020, but the foundation it was built on was one we no longer wanted to build new features on, and it had effectively no automated tests. Working software that blocks the future is a situation many businesses know well. Our answer was to rebuild it from the ground up - without taking it offline and without touching a single customer record.

What we built

For restaurants, SafestMenu covers the whole menu workflow: menus with categories and products, prices, allergens, spiciness and vegetarian markers; styling down to colors, fonts, currency and tone of voice; a mobile menu guests open by scanning the QR code; and everything available in six languages. A free plan with one menu and five products serves independent restaurants, and paid subscription plans serve small chains. AI features run on a simple token system - a text generation costs one token, a photo five, every account starts with 100 free tokens, and subscriptions top them up.

Behind the scenes, the product now exists twice: the original version, built since 2020, and a complete rebuild on modern foundations - roughly 49,000 lines of code across both generations. The defining rule of 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 their usual password, every menu and photo stays exactly where it was, and switching over works like flipping a switch - if anything looks wrong, we flip it back.

How we built it

We rebuilt the product feature by feature against the running original, held to written guardrails. A 1,355-line migration plan records, bug by bug, whether old behavior should be fixed or preserved exactly, because customers often depend on quirks. A tracker lists every feature of the old product and whether the new one matches it, checked against a live running copy of the system rather than on paper.

The safety net is tests. The original had effectively none; the rebuild has 1,106 automated tests, with a standing rule that they cover at least ninety percent of the code. Even details like photo processing reproduce the old behavior precisely, with a check that finds and regenerates any missing image before switchover. AI photo requests pass a moderation step before anything is generated.

What this build demonstrates

SafestMenu is where we test the discipline we sell. The rebuild matches the old product feature for feature, and the remaining steps before switchover are final preparations and manual checks, not new code. The pattern - rebuild the application, leave the data where it is, reproduce old behavior down to its quirks, and prove everything with tests - is the one we bring to clients whose systems have outgrown their foundations but cannot afford to lose their data, their users, or their uptime.