DEV Community: Raktim Ranjit

We Built an Offline-First, Open-Source Restaurant POS — Because Restaurants Can't Afford to Go Offline

Raktim Ranjit — Fri, 28 Aug 2026 06:06:04 +0000

A restaurant can survive a lot of things.

A slow day.

A broken printer.

A supplier arriving late.

But when the internet goes down during a busy dinner service, things can get chaotic very quickly.

Orders stop moving.

Kitchen tickets get delayed.

Bills become harder to process.

Tables become difficult to track.

And suddenly, the restaurant's most important operational system depends on something it doesn't control: the internet.

That problem is what led us to build OrderRestro.

OrderRestro is an open-source, offline-first restaurant management system designed specifically around restaurant operations — not a generic retail POS with a restaurant menu added on top.

The project is available on GitHub:

https://github.com/Raktim94/nodedr-restaurant-pos

It is built with:

Next.js
TypeScript
NestJS
PostgreSQL
Prisma
Socket.IO
Tailwind CSS
Docker
pnpm + Turborepo

And it is licensed under AGPL-3.0.

The problem with "everything in the cloud"

Cloud software is convenient.

There is no server to maintain.

Updates can happen centrally.

Data can be accessed remotely.

For many businesses, that's a great trade-off.

But restaurants have a different operational environment.

A restaurant might have:

A cashier at the POS
Servers using tablets
A kitchen display
A host managing reservations
A manager checking inventory
Multiple devices connected to the same local network

Most of these operations don't actually require the public internet.

They require the local network.

So we asked a simple question:

What if the restaurant's POS worked perfectly even when the internet disappeared?

That became one of the core architectural decisions behind OrderRestro.

Offline-first, not "offline as a fallback"

There is an important distinction here.

We didn't want to build a cloud application that happens to have a few offline features.

We wanted the restaurant to be able to run its core operation locally.

The default architecture is simple:

             RESTAURANT LAN

    ┌─────────────────────────┐
    │     Local Server        │
    │                         │
    │  Next.js + NestJS       │
    │  PostgreSQL             │
    │  Socket.IO              │
    └────────────┬────────────┘
                 │
      ┌──────────┼──────────┐
      │          │          │
    POS       Kitchen     Tablet
   Screen      Display    / Phone

The restaurant can have one local machine running OrderRestro.

Every device connected to the restaurant's Wi-Fi or Ethernet network can access it.

If the WAN connection disappears, the restaurant's local system can continue operating.

Orders can still be created.

Bills can still be processed.

Kitchen tickets can still move.

Tables can still be managed.

Receipts can still be printed.

That is the fundamental idea behind the architecture.

Why build a restaurant-specific POS?

One of the decisions we made early was not to turn our existing retail POS into a restaurant POS.

Retail and restaurants look similar from a distance.

Both sell products.

Both need billing.

Both need inventory.

Both need customers.

But operationally they are very different.

A retail transaction might look like:

Scan product
↓
Add to cart
↓
Take payment
↓
Print receipt

A restaurant transaction is closer to:

Customer arrives
↓
Table assigned
↓
Order taken
↓
Modifiers selected
↓
Kitchen receives KOT
↓
Multiple kitchen stations prepare food
↓
Food served
↓
Additional orders
↓
Bill split / merge
↓
Payment
↓
Table becomes available

The system needs to understand the restaurant floor and kitchen.

That means tables, reservations, waitlists, kitchen stations, KOTs, modifiers, recipes, inventory, customer history and much more.

Trying to force all of that into a retail schema would eventually make both systems worse.

So OrderRestro became its own codebase.

What is actually inside OrderRestro?

The current project already covers a large portion of the restaurant operation.

POS & Billing

The POS supports:

Dine-in orders
Takeaway
Delivery orders
Split bills
Merged bills
Discounts
Tips
Gift cards
Loyalty points
Multiple payment methods
Refunds
GST/VAT handling
Printable receipts

The goal is to keep the workflow fast.

A restaurant employee shouldn't have to navigate through five different screens just to close a table.

Tables and Floor Management

Restaurants aren't just a list of transactions.

They have a physical floor.

OrderRestro provides a visual table layout where staff can see the current state of the restaurant.

For example:

┌────────┐ ┌────────┐ ┌────────┐
│ Table 1│ │ Table 2│ │ Table 3│
│ FREE │ │ SEATED │ │RESERVED│
└────────┘ └────────┘ └────────┘

┌────────┐ ┌────────┐ ┌────────┐
│ Table 4│ │ Table 5│ │ Table 6│
│ SEATED │ │ FREE │ │ WAITING│
└────────┘ └────────┘ └────────┘

Staff can manage seating, reservations and the waitlist from the same operational view.

Kitchen Display System

This is one of the most important parts of a restaurant POS.

A traditional workflow often looks like:

POS
↓
Printed KOT
↓
Kitchen
↓
Someone loses the paper
↓
Customer waits

We wanted something more reliable.

OrderRestro sends kitchen tickets to a live Kitchen Display System.

NEW
↓
ACCEPTED
↓
PREPARING
↓
READY

Tickets can be routed to kitchen stations, and the display can show priority and elapsed-time information.

Because the system uses Socket.IO for realtime events, screens don't need to continuously poll the server waiting for changes.

The server can push the update when something actually happens.

Menu and Combo Management

Restaurants need more than a product catalogue.

A menu item can have modifiers:

Burger
├── Size
│ ├── Regular
│ └── Large
│
├── Cheese
│ ├── None
│ └── Extra
│
└── Add-ons
├── Fries
└── Drink

OrderRestro supports categories, modifiers, combo meals and item availability.

This becomes especially useful during busy service when something sells out.

Instead of continuing to sell an unavailable item, staff can mark it unavailable.

Inventory Based on Ingredients

Restaurant inventory is different from retail inventory.

A retail store might sell:

1 × Coca-Cola
1 × Notebook
1 × Shirt

A restaurant sells:

1 × Chicken Biryani

But internally that might consume:

Rice
Chicken
Oil
Spices
Onions
Yogurt

That's why OrderRestro uses recipe-based inventory.

The system can track ingredients rather than only finished dishes.

It also includes:

Recipe costing
Suppliers
Purchase orders
Goods receipts
Batch/lot tracking
Expiry tracking
Waste logging
Automatic stock deduction
Weighted-average costing

This gives restaurant owners a much better picture of where food costs are actually going.

Customer Profiles and Loyalty

A restaurant's relationship with a customer shouldn't end when the bill is printed.

OrderRestro includes customer profiles with:

Visit history
Loyalty points
Feedback
Customer information
Gift cards

That creates the foundation for future CRM and marketing functionality.

The long-term goal is to connect the operational side of the restaurant with customer retention.

The architecture

The project is a monorepo built around a fairly conventional modern TypeScript stack.

nodedr-restaurant-pos/
│
├── apps/
│ ├── backend/
│ │ └── NestJS
│ │
│ └── web/
│ └── Next.js
│
├── packages/
│ └── types/
│ └── Shared Zod schemas
│
├── docs/
│
└── casaos/

The major pieces are:

Frontend

Next.js + TypeScript

The web application handles the POS, dashboards, kitchen display, tables, reservations, inventory and administration.

Backend

NestJS

The API provides the business logic and REST endpoints.

Database

PostgreSQL + Prisma

Restaurant data needs relational consistency.

Orders, bills, tables, customers, inventory, recipes and reservations all have relationships that benefit from a relational database.

Realtime

Socket.IO

Used for realtime restaurant events such as:

Kitchen tickets
Table updates
Order updates
QR-order status
Infrastructure

Docker Compose

The complete stack can run together as containers.

One of the most important rules: money belongs on the server

A POS is not a place where you want business-critical calculations happening only in the browser.

Prices, taxes, discounts and loyalty calculations need to be authoritative.

OrderRestro follows a server-authoritative model:

Client
│
│ "I want to buy this"
▼
Backend
│
├── Validate item
├── Calculate price
├── Calculate tax
├── Apply discount
├── Calculate loyalty
└── Save transaction
│
▼
PostgreSQL

The frontend is responsible for the interface.

The backend is responsible for deciding what the transaction actually means.

This matters even more when the system handles GST/VAT, refunds, loyalty balances and inventory.

Why PostgreSQL instead of SQLite?

An offline-first application doesn't necessarily mean "use SQLite."

We wanted the database architecture to support the operational complexity of a restaurant system.

PostgreSQL gives us:

Strong relational modelling
Transactions
Concurrent access
Mature indexing
A well-established ecosystem
A path toward larger deployments

And because PostgreSQL runs locally inside the Docker stack, using it doesn't require a cloud database.

The restaurant can still own the entire deployment.

Self-hosted means something different here

OrderRestro doesn't require the restaurant to send its operational data to our servers.

The default deployment can look like:

Restaurant
│
▼
Local Server
│
├── Application
├── PostgreSQL
└── Restaurant Data

The same application can also be deployed on a VPS when remote access is desirable.

There isn't a separate "cloud edition."

It's the same application.

That flexibility is intentional.

Open source changes the relationship

OrderRestro is released under the AGPL-3.0 license.

That means the project isn't simply:

"Here's a free demo. Pay us when you need the real thing."

The source is available.

You can inspect it.

You can self-host it.

You can modify it.

You can contribute to it.

And if you build a modified network service under the AGPL requirements, the license includes corresponding source-sharing obligations.

For a system that manages a business's operational data, being able to inspect what you're running can be valuable.

There is still a lot left to build

We don't want to pretend that a restaurant ERP/POS can be finished in a weekend.

The current system already covers core POS, kitchen, tables, reservations, CRM and inventory functionality.

But the roadmap is much larger.

Some of the areas planned for future phases include:

Deeper procurement
Delivery management
Full online ordering
Multi-branch management
Advanced analytics
Marketing campaigns
Accounting
Finance
Maintenance
Documents
More integrations
Advanced security features

The roadmap is intentionally public.

You can see the project and its current status here:

GitHub repository

Why not just use a SaaS POS?

That's a completely reasonable question.

For many restaurants, SaaS is the right answer.

You get support, hosting and a managed environment.

But there are businesses with different requirements.

For them, questions like these matter:

What happens if our internet goes down?

Where is our data stored?

Can we modify the system?

Can we run it on our own infrastructure?

Are we locked into a vendor?

Can we integrate it with our existing systems?

Do we really need another monthly subscription?

OrderRestro is an attempt to provide a different answer.

Not necessarily a better answer for everyone.

Just a different one.

The bigger idea

The interesting part of building restaurant software isn't the POS screen.

It's understanding the restaurant as a distributed system.

There are multiple actors:

Customer
│
▼
Server ────────► POS
│
▼
Kitchen
│
▼
Service
│
▼
Table
│
▼
Billing
│
▼
Customer CRM

At the same time:

Inventory ──► Recipes ──► Orders
▲ │
│ ▼
Purchasing ◄──────────── Sales

And:

Reservations
│
▼
Tables
│
▼
Orders
│
▼
Customers

A good restaurant system isn't just billing software.

It is the operational layer connecting all of these workflows.

That's the problem we're trying to solve.

Try it yourself

The easiest way to explore OrderRestro is through the project website:

https://orderrestro.nodedr.com/

The source code is available here:

https://github.com/Raktim94/nodedr-restaurant-pos

The project can be run with Docker, and the repository includes installation and development documentation.

For a quick-start deployment:

git clone https://github.com/Raktim94/nodedr-restaurant-pos.git

cd nodedr-restaurant-pos

./install.sh

Then open:

http://localhost:1995

You can also run the stack on a local restaurant server, VPS, or compatible home-server environments.

We're building this in public

OrderRestro is still actively developing.

That means there are bugs.

There are unfinished modules.

There are architectural decisions that will evolve.

And there are probably things we've designed incorrectly.

That's also the reason we're building it in the open.

If you're interested in:

Open-source POS systems
Restaurant technology
Offline-first applications
Next.js
NestJS
PostgreSQL
Prisma
Socket.IO
Self-hosted software
Restaurant operations
Building vertical SaaS alternatives

take a look at the repository.

Issues, ideas and contributions are welcome.

Repository: https://github.com/Raktim94/nodedr-restaurant-pos

Product: https://orderrestro.nodedr.com/

Final thought

A restaurant shouldn't stop taking orders because its internet connection stopped working.

That sounds obvious.

But once you start designing the entire system around that principle, it changes almost everything:

How you deploy.

How realtime communication works.

Where data lives.

How the database is selected.

How the frontend talks to the backend.

How you think about backups.

And ultimately, how much control the restaurant has over its own software.

That's why we built OrderRestro as offline-first, self-hosted and open source.

Not because cloud software is bad.

Because sometimes the best cloud architecture is the one that still works when there is no cloud.

Why I Built an Offline-First POS Instead of Another Cloud POS

Raktim Ranjit — Mon, 03 Aug 2026 06:52:55 +0000

Every few years, a new cloud-based POS platform promises to simplify running a business. They usually offer automatic updates, dashboards, and access from anywhere.

But while working with businesses, I noticed one recurring problem:

When the internet goes down, business shouldn't stop.

That simple observation led me to build NodeDR POS, an offline-first, self-hosted point-of-sale system that continues working even without an internet connection.

Live Demo: https://pos.nodedr.com/

The Problem

Cloud POS systems have many advantages, but they also introduce a dependency that many businesses don't think about until something goes wrong.

Common issues include:

Internet outages preventing sales
Monthly subscription costs
Vendor lock-in
Customer and sales data stored on third-party servers
Slow performance caused by network latency

For many businesses, a POS isn't just another web app—it's the heart of daily operations. Every second spent waiting means customers waiting in line.

I wanted something different.

The Goal

My design goals were straightforward:

Work completely offline
Keep all business data local
Be easy to deploy
Use modern web technologies
Require minimal maintenance
Deliver a fast checkout experience

Rather than building another SaaS product, I focused on making software that businesses could own and run themselves.

The Architecture

Instead of relying on cloud infrastructure, NodeDR POS runs entirely on the local machine.

Browser
│
▼
Next.js Frontend
│
▼
Express API
│
▼
SQLite Database

Everything lives on the same device or local network.

No external API is required to process a sale.

That means:

Billing continues without internet
Product searches remain instant
Reports are always available
Customer information stays local
Why I Chose SQLite

Whenever developers hear "production database," they immediately think PostgreSQL or MySQL.

For a POS system, I questioned that assumption.

Most businesses have:

One checkout terminal
A few employees
Thousands of products—not millions
Continuous small transactions

SQLite turned out to be an excellent fit.

Benefits include:

Zero database administration
ACID-compliant transactions
Extremely reliable
Very fast local reads and writes
Easy backups
One less service to manage

For larger deployments with many concurrent terminals or multiple locations, PostgreSQL may make more sense. But for the majority of small and medium-sized businesses, SQLite keeps the stack simple and dependable.

Why Build It as a Web App?

Instead of creating a native desktop application, I chose a browser-based interface.

This provides several advantages:

Cross-platform compatibility
Easier updates
Modern UI development with React
Local network access from multiple devices
No operating system-specific builds

The application is still hosted locally, so businesses get the flexibility of a web app without depending on the cloud.

Features

Current features include:

Barcode scanning
Fast product search
Inventory management
Customer management
Loyalty rewards
Credit account tracking
Returns and refunds
Sales analytics
Receipt printing
Role-based permissions
Low-stock alerts
Docker deployment

The goal isn't to include every feature imaginable—it's to provide the features businesses use every day while keeping the experience fast and reliable.

Challenges

Building an offline-first application isn't simply removing API calls.

It changes how you think about software.

Some of the biggest challenges included:

Designing workflows that never assume an internet connection
Keeping the UI responsive with large inventories
Supporting hardware such as barcode scanners and receipt printers
Managing local backups and recovery
Planning for future multi-store synchronization

These challenges forced me to prioritize resilience over complexity.

What I Learned

A few lessons stood out during development:

Simplicity scales surprisingly well

Choosing simpler technologies often results in software that's easier to maintain and more reliable.

Offline-first changes your mindset

Instead of asking, "What happens when the server is unavailable?" you ask, "Can the application function without any server at all?"

Performance matters

A cashier notices delays that users of many other applications would never see.

Every interaction should feel instantaneous.

What's Next

I'm currently working on:

Multi-store synchronization
Better hardware integrations
More reporting capabilities
Plugin support
Automated backups
Additional payment integrations
Final Thoughts

Cloud software has its place, but not every business needs to depend on a remote server to complete a sale.

For many retailers, reliability is more valuable than another online dashboard.

Building NodeDR POS has been an opportunity to explore how modern web technologies can deliver the convenience of a web application while maintaining the resilience of traditional desktop software.

If you're interested in offline-first architecture, self-hosted software, or building modern POS systems, I'd love to hear your thoughts and feedback.

🌐 Project: https://pos.nodedr.com/

I'm happy to answer questions about the architecture, technology choices, or development process in the comments.