OrderSpot: Building a Whole Point-of-Sale Suite

After years of designing point-of-sale software for others, I wanted to know what a complete suite would look like, conceived in one piece and built with today's tools. OrderSpot came out of that.

A suite is not several applications

The suite includes a till, a kiosk, a preparation display, an order-call screen and a driver app. Everything started in a single repository. We split it into independent Flutter applications sharing one foundation: the design system, French, English and Arabic, networking and the dialogue with hardware.

That choice has a direct consequence. An improvement to the foundation benefits every application, and each one can ship without waiting for the others.

The store must not depend on the internet

This is the most important architectural decision. A small server is installed on a computer in the store. It holds a local database, exchanges in real time with devices on the network, and synchronises with the cloud through a queue: data leaves every few seconds and, if the connection drops, it waits.

Devices discover it on the local network by themselves and pair with a short code, with no network setup for the team.

An AI agent in the store

This local server also exposes its functions to an AI agent through the MCP protocol: listing active orders, declaring an item out of stock, transferring an order. The agent can run on a local model or go through the cloud. In other words, AI is not a layer added at the end. It was planned into the architecture.

What I left aside

You have to know how to arbitrate. NF525 certification demands considerable work, and I deliberately left it out of this first version to take the product experience all the way. That is exactly the kind of decision you have to own and write down.

A suite holds together through what its applications share, and what they can still do when nothing answers.