OrderOS

Overview

OrderOS (internally BisOS) is a multi-tenant SaaS product for small food and service businesses that have outgrown notebooks and spreadsheets but cannot justify — or operate — full accounting software.

It covers everything between "a customer asked for something" and "the money is in the bank": clients, orders or appointments, stock, deposits, balances, invoices and a subscription that pays for the platform itself.

What it looked like before

The businesses OrderOS was built for all share one shape: the owner is the system. The order exists in their memory, the stock level exists in their head, and the money owed exists on a slip of paper.

Three failures repeat across that pattern:

1. Stock drift. Without deduction on order, the count and reality diverge until a customer is told yes and receives no.
2. Double bookings. Two people holding two diaries is a scheduling conflict with a client in the middle of it.

What I built

One system that fits two kinds of business

The hardest product decision was admitting that a bakery and a salon do not run the same business. OrderOS ships two modes on one codebase:

• Inventory mode — products, stock on hand, low-stock warnings, stock deducted when an order is placed.
• Timeslot mode — services with durations, appointment slots, and overlap detection that refuses a double booking before it can be saved.

Everything downstream — the dashboard, the navigation, the order form — branches on the client's mode. One platform to maintain, two products to sell.

Orders that add up on their own

An order is one header plus any number of line items, so a mixed basket is a first-class citizen rather than a special case. Totals are derived, never stored twice:

balance due = SUM(line item totals) - deposit paid

Because the balance is computed from records rather than typed in, it cannot quietly drift out of sync with the order.

Paying for the system, handled properly

The platform bills for itself. Outbound payment parameters are signed with the payment provider's signature scheme over sorted, URL-encoded values, and the inbound payment notification verifies that signature with a constant-time comparison before granting access. Successful payment activates the account; the admin panel controls expiry and payment state, so a client can be onboarded, extended or suspended without touching the database.

Separate logins, separate data

Two audiences share one app and never see each other's data:

• Clients see their own orders, clients, products and revenue — and only their own.
• Admins create accounts, manage subscriptions and inspect platform state.

Every user-scoped query is filtered by owner at the database layer, so a missing filter fails closed rather than leaking a neighbouring business's data. There is no public sign-up: accounts are provisioned deliberately.

Built to be depended on

Small decisions that separate a demo from a product you can run for a paying client:

• A health endpoint for uptime monitoring and hosting probes.
• Graceful shutdown with a forced-exit fallback.
• Rate limiting on the API surface and, more tightly, on authentication.
• Secure, HTTP-only session cookies in production, with proxy trust configured so that client IPs and protocol are correct behind the host's load balancer.
• Credentials held only in a gitignored environment file — never in the repository.

How it is put together

| Layer | Choice | Why | | --- | --- | --- | | Runtime | Node.js 18 (CommonJS) | Ubiquitous, stable, cheap to host | | Framework | Express 5 + EJS | Server-rendered pages, minimal client JavaScript | | Data | Turso (hosted libSQL) | Managed SQLite with an HTTP client that suits serverless hosts | | Auth | express-session + bcrypt | Simple role separation without an identity provider | | Payments | PayFast (signed, webhook-verified) | Local payment rails, subscription-safe | | Documents | pdf-lib | Invoices rendered from live data, no template drift | | Deploy | Render, production mode | Zero-ops deployment with health checks |

What is different now

A business running OrderOS stops keeping a parallel record of itself. The order the client placed, the stock it consumed, the deposit they paid and the invoice they received are all the same record read from different angles.

That is the whole point of the platform: one place where the truth lives, with the reporting falling out of it instead of being assembled after the fact.

Decisions worth explaining

• One codebase, two modes over two products — a fraction of the maintenance for the same addressable market.
• Server-rendered over a client framework — works on a cheap phone on a slow connection, and the whole team can read it.
• Derived balances over stored totals — impossible to disagree with itself.
• Signed payments with verified webhooks — the subscription gate cannot be bypassed by replaying a URL.

What I would build next

The honest backlog, prioritised:

1. Atomic order writes — wrap the order header, line items and stock deduction in a single database batch so a crash cannot half-write an order.

2. Persistent session store so deploys no longer log everyone out.

3. CSRF protection across all form submissions.

4. Automatic subscription expiry driven by the stored expiry date rather than a manual admin toggle.

5. Backup strategy and a documented restore drill for client data.

6. Invisible margins. Without recorded cost prices, "busy" and "profitable" look identical from the outside.

And beneath all three: no shared place where the numbers live.