Front of house Built
Tabs, seat and amount splits, modifiers, courses, voids, comps and discounts with manager approval, split tender, a customer-facing display, and a quick kiosk layout for counters.
Free and open source · no cut of your orders
The point-of-sale that runs your restaurant, not your bill.
Till, kitchen screen, floor plan, stock, staff, delivery and WhatsApp ordering — one system on hardware you own, in your currency, in your country. Nobody takes a percentage. There is no subscription. There is no account to lose.
- Your database, your building
- Any currency, any locale
- MIT or Apache-2.0
0%
Taken from every order. There is no platform fee to take one.
0
Outbound network calls on a fresh install. Nothing phones home.
0
Interface languages shipped, including Arabic, Zulu and Xhosa.
0
HTTP endpoints on the API you host, documented and yours to call.
Counted from the repository this page is built from: languages are the files in src/i18n/locales; endpoints are HTTP verb registrations on the router in non-test Go. The two zeroes are properties of a fresh install with no optional integration configured, not settings you have to find. Nothing here is rounded up for effect.
Pre-1.0, and honest about it.
The till, the kitchen screen, the floor plan, stock, staff, reports and WhatsApp ordering are built and in daily-service shape. Multi-branch sync, offline service and online card payments are not finished, and this page says so wherever they come up — with a chip on every claim. The Features chapter and the Roadmap keep the same ledger.
The tour
Every screen you'd stand in front of during service
These are screenshots of the running application, generated from the repository — not mockups, and not a designer's idea of a restaurant. Tap any image to see it full size.
/pos/workspace
Menu grid, open tab, running total. Split by seat or by amount at the point you take payment.
Take an order without thinking about the software
Tabs stay open across the shift. Modifiers, courses and seat numbers are on the item, not buried in a submenu. Voids, comps and discounts ask for a manager's PIN and land in the audit log with a name against them.
- Split any way — by seat, by item, or by an arbitrary amount, with split tender across cash and card.
- Course control — hold, fire and re-fire courses so the kitchen sends starters before mains.
- Quick POS — a stripped kiosk layout for counters and takeaway, on the same data.
/kds/expo
Expo view. Each station gets only the items routed to it; expo sees the whole ticket.
A kitchen screen the kitchen will actually use
Items route to the station that cooks them — grill, fry, cold, pass — so nobody reads a ticket that isn't theirs. Expo holds the whole order together and only lets it go when every station has bumped.
- Fire timers on every ticket, so a table that has been waiting is visible from across the pass.
- Course fire on bump — clearing starters releases the mains automatically.
- The 86 list is shared — mark it out in the kitchen, it disappears from the till and the online menu.
/floor
Tables laid out the way the room actually is, coloured by what each one is doing.
See the room, not a list of table numbers
Lay the plan out to match the floor. Every table carries its session — who is on it, what stage they're at, how long they've been sat, which server owns it. Turnover falls out of that instead of being guessed at.
- Sections and assignment — hand a section to a server and the tickets follow.
- Reservations and the waitlist land on the same plan — no separate booking service in the middle.
- Turn time is measured from the session, not estimated — you can see which sections are running slow while there's still time to help.
/menu
Every item carries its recipe, so its cost and margin are computed rather than typed in.
A menu that knows what it costs you
Build an item out of ingredients and sub-recipes and BeepBite costs it recursively — a sauce used in four dishes is priced once and flows into all four. When an ingredient price changes on a goods receipt, every margin that depends on it moves with it.
- Modifiers and prep steps that reach the right station on the kitchen screen.
- Ingredient price history — see what you were paying for lamb six months ago.
- Menu engineering ranks items by margin against popularity, so you know what to push and what to cut.
/inventory/purchase-orders
Purchase orders through to three-way match: what you ordered, what arrived, what you were billed.
Stock control that closes the loop
Raise a purchase order against a supplier, receive it, and match the invoice against both. The three numbers that should agree are shown together, so a short delivery you were still charged for is visible instead of absorbed.
- Reorder suggestions from actual depletion, not a fixed par sheet.
- Waste logging that shows up against theoretical usage instead of vanishing.
- Theoretical vs actual COGS — the gap between what you should have used and what you did.
/
The first screen of the shift. Reports sit behind a capability, so not every account sees them.
The numbers that change a decision
Daily sales and an hourly heatmap are on screen today, which is what tells you when to roster and when to send someone home. Four more reporting views — menu engineering, labour hours, theoretical-versus-actual COGS and revenue by tender — exist in the database and are queryable now, but do not have a screen yet.
- Read-only views over your own database — you can query all six yourself today, screen or no screen.
- Gated by capability —
can_view_reportsis a permission, not an honour system. - Export what you like — it's your Postgres. Nothing is locked in a vendor's warehouse.
Features
Everything that has to work on a Friday night
One binary. Every feature in it is in every copy — there is no tier that unlocks the row below.
Built in daily-service shape
Partial works, with a caveat we name
Planned designed, not finished
Kitchen Built
Per-station routing, an expo view, a fan-out queue, fire timers, course-fire-on-bump and a shared 86 list that reaches the till and the online menu at once.
Stock & purchasing Built
Suppliers, purchase orders, goods receipts, three-way invoice matching, stock movements, waste, reorder suggestions and ingredient price history.
Money at the counter Built
Cash drawer sessions with denomination counts and a blind close, paid-in and paid-out, gift cards, store credit, house accounts and invoicing.
Staff & time Built
Role and capability based access, a PIN actor overlay with lockout after five bad attempts, a time clock, tip pools, and a payroll export — the run itself stays with your accountant.
Reporting Partial
Six read-only reporting views over your own database. Daily sales and the hourly heatmap have screens; menu engineering, labour hours, COGS variance and revenue by tender are queryable but not yet on a screen.
WhatsApp ordering Built
Guests order in the thread they already use, and get a message when the food is ready instead of a buzzer. Runs on your Meta Cloud API credentials; without them the whole path stays dark.
Delivery & pickup Built
Polygon delivery zones, a driver portal with assignments, shifts and location pings, pickup slots, and a public tracking page per order with live progress and an ETA. The map appears once an order is out for delivery; the driver's own position is withheld from anonymous links by a privacy gate.
Guests & loyalty Built
Loyalty and stamp cards, promotions, coupons, and reviews you can answer in your own name — on your own page, not on someone else's directory.
Isolation & audit Built
Row-level security in the database, not just in the app. An audit log with a name against every void and comp. Idempotency on writes so a double tap is not a double charge.
Currency, tax & locale Built
Currency, tax convention, timezone, locale and dial code all resolve per location from configuration. No hardcoded country. No hardcoded currency. See it change below.
Multi-branch sync Planned
The ownership model and the local operation log are built and running. The replication round is not — two instances do not exchange data today. What exists, and what doesn't.
Discord, Slack and email ordering are not built. The seam they would plug into (internal/channel) exists, which makes writing one cheaper — it does not make one exist. Offline service is scaffolding that nothing in the running app imports yet.
Orders in, food out
One order stream, whatever the order came in on
An order from the till, a WhatsApp thread and a QR code at table 12 are the same object by the time the kitchen sees it. There is no second system to reconcile at close.
Where orders start
Till staff
WhatsApp your number
Your store page collection / delivery
QR to that page guest phone
Discord · Slack · email not built
Your hardware
Go API one binary
PostgreSQL your database
Till · Kitchen · Floor browser
Out to the street
Driver app assignments
Order page per order
Ready message WhatsApp
Built solid boxes
Planned dashed box
Nothing in the middle column leaves your building.
Messaging
Your guests already have the app
No download, no account, no loyalty app nobody opens twice. A guest messages your number, orders in the thread, and gets told when the food is up. The buzzer stays in the drawer.
- Your number, your credentials. BeepBite talks to the Meta Cloud API with keys you supply. There is no BeepBite number pool and no shared sender.
- Entirely optional. Leave the credentials out and the whole path stays dark — the rest of the system does not notice.
- Same order object. A WhatsApp order hits the kitchen screen exactly like one rung in at the till.
More than one shop
Multi-branch sync, drawn honestly
This is the shape of the design and the state of the build. It is not a feature you can turn on today, and we would rather show you the diagram with a warning on it than sell you the picture.
High Streetbranch-a
- Menu & pricesgroup
- Tonight's ticketsbranch
- Cash sessionsledger
Harbourbranch-b
- Menu & pricesgroup
- Tonight's ticketsbranch
- Cash sessionsledger
Airportbranch-c
- Menu & pricesgroup
- Tonight's ticketsbranch
- Cash sessionsledger
The replication round Not built
All 149 tables are classified — group-owned, branch-owned, append-only ledger or node-local — and the layer that would turn a row write into a replicated operation is written and tested. It is not switched on in the server.
What is missing, precisely: the emitter is never attached outside its own tests, so no operations are produced at runtime. Above that there is no push/pull round, no peer enrolment flow and no apply path. Two BeepBite instances do not exchange data. If you run three branches today, you run three independent installs. Do not buy into this expecting them to converge — read the roadmap for the committed sequence, and hold us to it.
Money
Your currency, your country, your card machine
BeepBite records what was tendered. It never stands between you and the money.
Try it. Nothing here is a special case.
There is no hardcoded currency in the application logic and no default locale — an earlier version had a symbol table and a ZAR special case, and removing both is exactly why this module exists. Decimal count, symbol placement, grouping and reading direction all come from CLDR.
The same numbers, re-read through a different locale — watch the decimals disappear on yen and grow to three on dinar. Interface translations ship for English, Afrikaans, Arabic, Spanish, French, Hindi, Portuguese, Xhosa and Zulu; this demo shows the money and date formatting, which is locale-driven for every language.
Maison Copper
—
2 × Lamb flatbread—
1 × Mint tea—
1 × Baklava—
Subtotal—
Tax (inclusive)—
Total—
Cash tendered—
Change—
Table 12 · Server: Nadia
Thank you
Thank you
Built How you get paid
- Cash, counted against a drawer session with a blind close.
- Card, on your own machine. BeepBite records the tender; the terminal you already have takes the money.
- Bank transfer, vouchers, cash-on-delivery and card-on-delivery as first-class tender types.
- Gift cards and store credit, issued and redeemed against the same balance.
- House accounts with account-level invoicing, for the regulars who settle monthly.
- Split tender across any combination of the above, on one bill.
Not that What we are not
- Not a payment facilitator. We never touch your settlement, hold your float, or sit in the flow of funds.
- No PCI scope. Card data never reaches the application, because the application never asks for it.
- No cut. Not on card, not on delivery, not on a WhatsApp order. There is no mechanism in the codebase to take one.
- Online card payments are not finished. The path is opt-in, compiled out of the default build, and its own integration tests currently fail. It has never been run against a live processor. The chapter says so too.
- Not certified. Nobody has audited a deployment you run, because there is no single operator to audit.
Pricing
There is no price. That is the whole page.
Not a free tier. Not free for the first year. Not free until you pass a revenue threshold. Free, because there is no company on the other end of this billing you.
0
per month · per till · per seat · per order · per branch
No subscriptionThere is no plan to be on, and no plan to be moved off.
No commissionNobody takes a slice of a delivery or a WhatsApp order.
No feature tiersOne binary. Every feature in it is in every copy.
No lock-inIt's your PostgreSQL. Export it, fork it, walk away with it.
Licensed MIT or Apache-2.0, your choice. What it costs you instead: a machine to run it on, a Postgres database, someone comfortable at a terminal for about half an hour at install, and the honest truth that there is nobody to call — there is documentation, an issue tracker and the source. If that trade is wrong for you, it is genuinely wrong, and we would rather you knew now. The FAQ goes through it properly.
Where it runs
One binary, on a machine in your building
Self-hosting is not a deployment option here. It is the only mode there is.
One shop, one machine Built
A Go binary and a PostgreSQL database on hardware you own. Browsers on the floor point at it. This is the shape BeepBite is actually built for, and the one that works today.
More than one branch Planned
Today: independent installs that do not talk. The ownership model and the operation log are built; the replication round is not. See exactly what exists.
Over a shared substrate Experimental
A research direction, gated behind preconditions in the roadmap. It may not land. It is named here only so you know it is not a shipping feature.
What actually needs to be reachable
- The till, kitchen and floor Browsers on your own network.No URL
- Reports and stock Same server, same network.No URL
- WhatsApp ordering Meta must be able to reach your webhook.Needs URL
- Your public store page Only if you want guests to order online.Needs URL
- Order tracking pages Only if guests follow deliveries.Needs URL
Everything optional is bring-your-own
- WhatsApp Your Meta Cloud API credentials:
WHATSAPP_TOKEN,WHATSAPP_PHONE_ID.Off by default - The assistant Your own LLM provider key, or nothing at all.Off by default
- Online payments A compile-time build tag you have to opt into.Compiled out
- Analytics There is no analytics. There is no code path for one.Does not exist
Supply none of these and BeepBite makes no outbound network calls at all. That is a property of a fresh install, not a setting you have to find.
# 1. a database createdb beepbite # 2. your settings — currency, tax, timezone, locale cp .env.example .env # 3. build the schema go run ./cmd/migrate up # 4. the API go run ./cmd/server # 5. the app npm install && npm run dev
Roughly half an hour, once, by someone comfortable at a terminal. After that it is a web page on your own network. Full walkthrough in the setup chapter. Postgres is required — the single-file SQLite install is planned, not done. The Go API is one binary; the web app is a static bundle you serve alongside it. Binaries are built for Linux and macOS on both Intel and ARM; Windows is not built.
No feature is described as working unless it works. If a claim on this page turns out to be wrong, that is a bug, and it gets fixed like one.— the rule this repository is written under, from ROADMAP.md
Questions
The things a restaurant owner actually asks
Short answers here, the long ones in the FAQ chapter.
What's the catch? Nothing is free.
You host it. That means a machine, a database, backups you take yourself, and nobody to phone at 8pm on a Saturday. In exchange there is no monthly bill, no commission, and no company that can raise your price or switch your features off. Whether that trade is good depends on your shop — but it is the whole trade, and there isn't a second one hidden behind it.
Which countries and currencies does it work in?
Any of them. Currency, tax convention, timezone, locale and dial code all resolve per location from your own configuration — there are no hardcoded country defaults left in application logic. Money is formatted through CLDR, so zero-decimal currencies like yen and won and three-decimal ones like Kuwaiti dinar come out right without a special case. The interface itself ships in nine languages.
Can I run several branches on it?
You can run several independent installs. You cannot yet keep them in sync — two BeepBite instances do not exchange data today. The ownership model and the local operation log are built, the replication round is not. If shared menus and consolidated books across sites are the reason you're here, BeepBite is not ready for you yet, and we would rather say that now.
Does it process card payments?
No, and deliberately. BeepBite records that a card tender happened; your existing card machine takes the money and settles to your bank as it already does. Card data never enters the application, so there is no PCI scope to inherit. An online-payment path exists for remote orders, but it is opt-in, compiled out of the default build, and its integration tests currently fail — do not plan around it.
Does it work if the internet goes down?
The till, kitchen and floor talk to a server in your own building, so a dead internet connection doesn't stop service — but a dead network does. There is offline scaffolding in the codebase that nothing in the running app uses yet, so we will not claim offline tolerance. WhatsApp ordering does need the internet, because Meta is on the other end of it.
Can you see my data?
There is nowhere for us to see it from. There is no BeepBite cloud, no telemetry, no account system we operate. A fresh install with no optional integrations configured makes no outbound network calls at all. The data is in a PostgreSQL database you administer.
What happens if the project stops?
Your install keeps running, because nothing about it depends on us being alive. The source is MIT or Apache-2.0 — fork it, pay someone to maintain it, or freeze it. The database is ordinary Postgres with a documented schema, so even walking away entirely, you leave with your data in a format anything can read.
What hardware do I need?
A machine to run the server and Postgres — a small desktop or mini PC is plenty for one site — and a browser on whatever you want the till, kitchen screen and floor plan to run on. Tablets work; so do cheap touchscreen all-in-ones.
Receipt printers: network ESC/POS printers are supported directly, including kicking the cash drawer through the printer's cable. USB printing is not finished — the handler is a stub. Browser printing works everywhere as a fallback. Barcode scanners work as keyboard-wedge devices with no driver. The setup chapter goes through it properly.
Who supports it?
Nobody, in the sense you mean. There is documentation, a public issue tracker, and the complete source. That is the honest answer, and it is the main reason not to choose BeepBite. If you need somebody accountable on a phone line during service, buy something with a support contract.
Reading, not ringing
Nobody to call — everything to read
Every chapter here is copied out of the repository by a script, so what you read cannot drift from what is in the code.
Documentation
Setup, the full user guide, the FAQ, features, security — and the developer chapters underneath them.
Issues
Bugs, questions and feature arguments, in public where you can read the answers.
Source
All of it. Read the code behind any claim on this page, including the ones with a warning on them.
Own your counter.
Half an hour to install. Nothing to sign. Nothing to cancel.
Pre-1.0 and under active work. Everything on this page that isn't finished is labelled as unfinished, and the roadmap keeps the same list.