Sharang Parnerkar

Posted on Feb 23 • Edited on Feb 25

I built an open-source alternative to Toast and Square for restaurant management

#webdev #typescript #react #opensource

The Problem

If you run a small restaurant, your options for online ordering and management are:

SaaS platforms like Toast, Square, or ChowNow — $100-300+/month with vendor lock-in
Old open-source projects — mostly PHP/Laravel, hard to extend, dated UIs
Build it yourself — months of work before you can take a single order

I wanted a fourth option: a modern, self-hosted, open-source platform that a developer could deploy in an afternoon.

Introducing KitchenAsty

KitchenAsty is an MIT-licensed restaurant ordering, reservation, and management system built as a TypeScript monorepo.

What it covers

For customers:

Browse the menu, add to cart, and place orders for delivery or pickup
Schedule orders for later or order ASAP
Pay with Stripe or cash on delivery
Track orders in real-time
Book table reservations
Leave reviews
React Native mobile app

For restaurant staff:

Manage menus with categories, options, allergens, and images
Kitchen display — a live Kanban board showing incoming orders
Process orders with one-click status progression
Manage reservations with table assignment
Create and track coupons
Moderate customer reviews
Staff management with role-based access

For the owner:

Dashboard with revenue trends, order analytics, and top-selling items
Multi-language support (6 languages)
Full settings panel for payments, email, orders, and more

Tech Stack

Layer	Tech
API	Node.js + Express
Admin & Storefront	React 18 + Vite
Mobile	React Native + Expo
Database	PostgreSQL + Prisma
Real-time	Socket.IO
Payments	Stripe
Styling	Tailwind CSS
Testing	Vitest + Playwright (330+ tests)
Language	TypeScript (strict mode everywhere)

Architecture Decisions

A few choices I made and why:

Monorepo with npm workspaces — Admin, storefront, server, and shared types all live in one repo. Changes to shared types are immediately visible everywhere. No publishing packages, no version mismatches.

Prisma over raw SQL — Type-safe database queries that catch errors at build time. The schema is self-documenting with 30 models and clear relationships.

Socket.IO for real-time — The kitchen display and order tracking need instant updates. Socket.IO made this straightforward with room-based broadcasting.

Separate admin and storefront apps — Different audiences, different concerns. The admin is a dense data-management tool. The storefront is a consumer-facing ordering experience. Sharing a single React app would have meant too many compromises.

Self-Hosting

The project is designed to be self-hosted with Docker. The docs site has a complete guide covering:

Server setup (Ubuntu/Debian)
Docker Compose deployment
Domain and DNS configuration
Reverse proxy with SSL (Nginx or Caddy)
Backups and maintenance

For local development, it's docker compose up -d for PostgreSQL, then npm run dev:server / npm run dev:admin / npm run dev:storefront.

By the Numbers

27,000 lines of TypeScript
30 database models
118 API endpoints
330+ tests (unit, integration, E2E)
6 supported languages
Full CI/CD with GitHub Actions

Contributing

The project is set up for contributors:

Contributing guide
Good first issues — small, well-scoped tasks with clear instructions
Help wanted issues — bigger features where input is welcome
Discussions — feature ideas, RFCs, and community chat

Areas where help is most needed: accessibility, i18n coverage, test coverage, and structured logging.

Top comments (5)

Muhammad Afsar Khan • Feb 24

This is an incredibly impressive project! The scope is massive—handling customer ordering, staff management, kitchen displays, and owner analytics in one monorepo is no small feat. 👏

I especially appreciate the architecture decisions section. It's clear you've put real thought into separating concerns (admin vs. storefront) and chosen tools for type safety (Prisma, TypeScript). That's the kind of detail that saves developers months of maintenance headaches later.

A few questions for you:

Real-world testing: Have you had a chance to test this in an actual restaurant yet? I'd be curious how the kitchen display board holds up during a Friday night rush with 50+ simultaneous orders.

Offline mode: Restaurants often have spotty WiFi. How does the system handle connectivity issues—especially for the kitchen display?

What's next: You mentioned accessibility and i18n as areas needing help. Are there specific i18n challenges (like RTL languages) you're prioritizing?

Also, kudos on the documentation—clear setup guides are what make open-source projects actually usable. I'll be starring this to follow along. ⭐

Sharang Parnerkar • Feb 24 • Edited

Hey,
Thanks for your motivating words and really good points!
I am planning to test this in one of my friends restaurant in a few weeks. I will let you know how it goes. But I am sure, we wont have 50 simultaneous orders to stress test the system, since it is a small getaway restaurant and we dont even have 50 tables to serve.
Offline mode is a really good suggestion, I will try to take some time out to think how it could be resolved.
I am currently based in EU so I will be working mostly on EU languages and their support for i18n first.
Also, in the coming week, I will be setting up a public demo on a small server so people can click around and get a feel. There is still a lot to be done, and a long list of features like

Developer dashboard (metrics, logs, tracing)
Customizable restaurant layout management, so each restaurant can allow customers to book the best table (sea-side, roof-top, etc...)
Add more roles to the admin panel like Legal, Developer, Marketing who have their scope restricted to only certain aspects of administration.
More separation of concerns for feedback, review management, coupons, analytics
And much more...

Thanks for starring and hope to get more feedback from you, as the project grows!

Muhammad Afsar Khan • Mar 1

Thanks for the update — really cool to hear this is moving toward a real-world test, even if it starts small. That first deployment is always the scariest (and most exciting) part.

The roadmap sounds solid. The customizable table layout feature especially caught my eye — that kind of flexibility is exactly what restaurant owners actually need, not just generic table management.

Quick thought on the public demo: if you want to make it feel polished, even a small attention to typography goes a long way. Menu displays, reservation flows — those tiny font choices shape how trustworthy the whole thing feels. (Obviously biased as the guy building FontPreview.online , but still 😄)

Looking forward to seeing how the friend's restaurant test goes. Keep me posted!