From handwritten orders to a connected restaurant.

A friend of mine runs a small restaurant. Like many independent businesses, much of their daily operation relied on handwritten orders, conversations between staff, and spreadsheets to keep track of finances. It was a familiar way of working, but as things got busier, keeping everything organized became increasingly difficult. The process of taking an order, getting it to the kitchen, and making sure it reached the right customer was taking more attention than it should.

We looked at ways to make things easier. There were plenty of restaurant management systems available, although most came with subscription costs and features that were difficult to justify for a business of their size. Simpler QR ordering platforms were more accessible, but often offered limited customization and fairly generic customer experiences.

I started developing restoOS as an alternative, initially focusing on the journey of an order from the customer's phone to the kitchen. The idea gradually grew into a web application connecting the different parts of restaurant service, from taking orders and preparing food to handling payments and keeping financial records.

I wanted it to be affordable to operate, flexible enough to suit the restaurant, and something its owner could maintain independently.

A familiar experience, made digital.

The visual direction took inspiration from a traditional restaurant menu book. Warm ivory surfaces, delicate dividers, dark typography, and a muted red accent give the interface a familiar hospitality feel. I paired Newsreader with Manrope to bring some editorial character to the menu while keeping the more functional parts of the application clear and readable.

The customer-facing menu became the starting point for this visual language. Food photography takes up much of the space, with categories and dish information arranged for easy browsing. Customers can explore the menu and add items without creating an account, only entering their name when they're ready to order. On desktop, the cart stays visible beside the menu, while on mobile it remains accessible through a persistent button showing the current total.

The experience is intentionally straightforward, with subtle transitions and feedback as customers make their selections. Once an order is submitted, the application validates and records it before it appears in the kitchen workspace. The kitchen receives an update, while the order itself remains stored in the system, so its progress doesn't depend on a notification being seen.

In the kitchen, the layout becomes more practical. Orders appear as tickets, with quantities, preparation notes, and their current status visible to staff. A separate summary brings together the dishes that need preparing across different orders, making it easier to understand the workload without losing track of individual requests.

Working through this flow also shaped how I structured the underlying product. An order might contain several dishes, but they won't necessarily be ready at the same time. Customers might order again while waiting, or settle their bill before everything has been delivered. I designed the system around transactions, orders, and individual portions so those activities could be tracked independently while remaining part of the same customer visit.

This gave the kitchen a way to mark individual portions as ready, while waiters could see what was waiting to be delivered. Payment and delivery were also kept separate, allowing the system to account for the different ways service unfolds throughout a visit.

The same records continue through each stage. When the kitchen marks a portion ready, it becomes part of the waiter's delivery queue. Payments are recorded against the portions they cover, and a transaction only closes once everything has been delivered and paid for, or cancelled. The management workspace draws on these records as well, so the restaurant's operational activity and financial information remain connected.

Different people, different ways of working.

The more I worked on the product, the clearer it became that each part of the restaurant needed a different view of the same information.

Kitchen staff are concerned with preparation. Waiters need to follow customers, additional orders, deliveries, and outstanding payments. Management needs a broader picture of the business. I organised these responsibilities into three workspaces, each with its own layout and navigation, accessible through a shared staff application.

This also reflects how smaller restaurants operate, where responsibilities can overlap and one person might take on several roles throughout the day. Staff can move between workspaces without needing a separate account for each.

Across the three environments, I kept the visual language consistent while adapting the interface to the task. The kitchen prioritises readable tickets and immediate actions, the waiter workspace centres on active customers, and management relies on summaries, tables, and filters to make larger amounts of information easier to navigate.

The management workspace grew out of another part of the restaurant's original workflow: its spreadsheets. Financial records had been maintained separately from orders and service activity, making it difficult to see everything in one place.

With restoOS, the overview brings together order values, payments received, outstanding balances, and the dishes customers order most frequently. The favourite-menu section gives the owner a simple view of which items are popular, alongside the broader activity of the restaurant.

I approached this part of the interface with a quieter layout, allowing the figures to establish a hierarchy before introducing more detailed information. The goal was to make the overview useful for a quick check while still allowing someone to explore the records behind it.

The finance dashboard extends this with a record of payments and expenses. Sales, receipts, and outstanding balances are treated separately, since an order placed today might not be paid until later. Keeping those distinctions visible gives the owner a more accurate picture of the restaurant's recorded activity.

Spreadsheet exports remain available too. The idea was to connect financial records more closely to the restaurant's daily operations while preserving a familiar format for reviewing them outside the application.

Made to be owned.

Accessibility was part of the project beyond the interface itself. I wanted small restaurants to have the option of running their own software without being tied to a recurring platform subscription or giving up control of their operational data.

restoOS was developed as an open-source, self-hostable application, with a standalone deployment option alongside a managed cloud configuration. Both use the same core service logic, even though the infrastructure behind them differs.

The application runs in a browser, with a server handling orders, payments, and the rules that keep those records consistent. For a standalone installation, it can run on a local server or VPS using SQLite. The cloud configuration uses PostgreSQL through Supabase, with the application hosted on Vercel.

These are different ways of running the same product, rather than separate applications. Self-hosting still requires maintenance, infrastructure, and proper backups, and the cloud configuration has its own provider integrations. But owners have a path to operate restoOS on infrastructure they choose, with access to their own records and the freedom to adapt the software.

I also kept the product focused on a single restaurant and kitchen. It covers ordering, preparation, waiter service, payments, and day-to-day business records, without trying to accommodate every feature found in larger enterprise systems.

What came out of it.

What began with a friend's restaurant has since become a more complete product, bringing together the customer experience, staff workflows, and management tools within one application. The work involved designing the interfaces alongside the service logic behind them, finding ways for different parts of the restaurant to share information while keeping each experience appropriate to the people using it.

There is still room to refine the product through real-world use, particularly during busy service and as the volume of records grows. For now, restoOS provides a working foundation for the everyday activities that first prompted the project, with the flexibility to keep developing around the restaurant's needs.