It started as a database migration

The restaurant already had its own CRM, initially assembled by the founder with AI tools and later refined by a frontend developer.

My task sounded straightforward: replace JSON files and localStorage with PostgreSQL.

But once I examined how the product worked behind the interface, it became clear that changing the database would not be enough. The backend was not designed for reliable daily operations, and too much of the product logic depended on a fragile technical foundation.

What began as a storage migration became a full backend rebuild.

The larger problem was outside the CRM

The restaurant used an external SaaS provider for its customer-facing website and mobile app.

The platform was expensive, but cost was not the only issue. Order status updates could fail to reach customers, menu changes were not always published on time, and products placed on the stop list could remain available for ordering.

For a delivery restaurant, these were operational problems rather than minor software inconveniences. An outdated menu or a missing status could lead directly to cancelled orders, manual calls, and frustrated customers.

The goal became larger: turn the restaurant's own system into the POS behind the existing website and app.

The integration was almost stopped before launch

Part of the integration had already been developed using the provider's documentation. But when it was time to connect the real restaurant, the provider said that API keys were not issued for custom POS integrations.

Only prebuilt integrations were officially supported — including the ones the restaurant was trying to replace.

After a series of discussions, the provider approved the custom system and granted access. The integration was first tested on a separate restaurant profile. The production restaurant then had to be recreated, its settings and menu transferred, and the connection configured again.

The challenge was no longer just building the software. It was getting a custom product into production inside an ecosystem that was not originally prepared to support it.

From a CRM to an operating system

The new platform became the restaurant's central workspace.

Orders from the website and app enter the system with the customer, address, items, payment details, delivery method, and operational notes. Employees manage the full order lifecycle from the same interface:

New → Preparing → Ready → Out for delivery → Delivered → Completed

Every status change is sent back to the customer-facing platform, while the restaurant keeps its own structured history of the order.

The system now brings together:

• order processing and status management;
• menu items, categories, modifiers, prices, and availability;
• separate settings for different branches;
• preparation and delivery timing;
• courier and branch performance;
• revenue, order, average-check, and peak-hour analytics.

Instead of adapting daily work to several disconnected tools, the restaurant now has one system built around its actual process.

Delivery became a measurable process

Completing an order is not the same as delivering it on time.

The platform compares the expected delivery time with the actual completion time and automatically calculates on-time deliveries, delays, and average lateness. Performance can be reviewed by courier or by branch.

This gave the owner a visible operational picture instead of relying on individual complaints or manually checking completed orders.

Control now. Independence next.

The restaurant no longer depends on the quality of a prebuilt POS integration. Orders, statuses, menu data, delivery performance, and analytics are managed within its own product.

The next stage is already in development: a customer-facing website and application connected directly to the same operational system.

Once launched, they will remove the remaining dependency on the SaaS provider and give the restaurant control over the entire digital journey — from browsing the menu to receiving the order.