AUXO

What it is

AUXO is a multi-tenant SaaS platform for companies that open physical outlets at scale — restaurant groups, café chains, retail estates. A customer gets a workspace, invites their team, and runs the whole life of an outlet inside it: the site they are considering, the project that builds it, the money it costs, the vendors who fit it out, and then — once the doors open — the tables, the kitchen, the stock, the guests and the daily checklists.

That last half is what changed this year. AUXO started as an expansion tool. It is now the system the outlet keeps using after the ribbon is cut.

Twenty-five modules, two hundred and twenty-nine tables, ninety-one thousand lines of TypeScript, 658 server calls — and a tenancy model built for the one failure a SaaS business cannot survive.

The problem it solves

Opening a restaurant is a construction project, a procurement programme, a licensing exercise and a hiring drive that all have to land on the same day. Opening twenty-five at once, across four cities, is a different problem — and almost every group doing it runs on spreadsheets, email threads and a WhatsApp group per site.

Then the outlet opens, and a second set of tools takes over: a reservations app, a POS, a stock sheet, an audit app, a marketing tool. None of them knows the outlet was ever a project. The sanctioned budget, the vendor who fitted the kitchen, the licence that expires in eleven months — all of it is in a different system from the one the manager looks at every morning.

AUXO’s premise is that this is one thread, not two products.

The journey — one outlet, start to finish

Every screen in AUXO sits somewhere on this line, and the hand-offs are built, not left to a human to remember.

ATLAS ─────▶ Projects ────▶ CAPEX ──────▶ Supply Chain ▶ Checklist ▶ Run
site scored  24 stages,     sanction by   RFQ · PO ·     155 items,  outlet
& approved   Gantt, tasks   category,     GRN · invoice  go-live     switched on:
                            revisions     · payment      gate        book, till,
                                                                     stock, ops

Where to open. ATLAS scores a candidate site on catchment, competitor density, white space and coverage, across 4 km neighbourhood grids of the whole network. A site that is approved becomes a project with one click — location, brand and geography carried across, never retyped.

Get it built. The project is provisioned with a 24-stage plan, a Gantt with a computed critical path, dependency graphs and a 155-item opening checklist. Drag a bar and everything downstream reschedules. Vendors are sourced by RFQ, committed by purchase order, received against goods receipts, and paid against invoices — with multi-level approvals at each hop.

Switch it on. When the project reaches go-live, AUXO turns the outlet on: operations, reservations, the till, the kitchen display and the stock ledger all wake up for that outlet, already knowing its brand, its floor and its vendors, because they were the project’s.

Control the money like a finance controller would

CAPEX in AUXO is not a budget-versus-actual tile. It is the financial spine of the build, modelled the way a CFO actually runs a programme:

• Sanction by category — civil, interiors, kitchen equipment, HVAC, electrical, technology and the rest — with revisions that go through approvals and keep the original figure beside the sanctioned one.
• Commitments and cash from the documents, not from a spreadsheet: every purchase order, goods receipt and invoice rolls up automatically, so committed, booked and paid are always what the paperwork says.
• Estimate at completion with headroom per category, and a decision list that surfaces exactly which outlet has blown which category by how much.
• A 90-day cash forecast built from what falls due on open orders and invoices, with retention and advances handled.
• A business case per outlet — revenue per month, payback, IRR and NPV against the sanction — so an opening is argued in the same terms Finance argues it.
• Capitalisation — what becomes an asset, at what class and useful life, with the GST credit that is claimable and the credit that is blocked.
• Benchmarks and templates — cost per square foot by concept and city, learned from the portfolio, so the next budget starts from evidence.
• A policy layer — approval bands, thresholds and who may sanction what — enforced at the point a purchase order is submitted, not audited afterwards.

Run the estate once it trades

The second half of the platform, built in eight phases this year.

Reservations. A host stand, a book with pacing per 15-minute slot, floor plans and table combinations, a waitlist, guest messaging with a consent ledger, and feedback after the meal. The same reservation the guest made is the one the till seats.

Point of sale. A native till and a kitchen display, per outlet. Bills settled while the network is down are queued as complete packets and posted when the server answers, booked exactly once by reference however many times they are retried. Day close produces a Z-report; the numbers reconcile to the ledger, not to a printout.

Materials. Recipes, the stock ledger, indents, transfers, base kitchen production, counts and theoretical-versus-actual food cost — on the same vendor engine as CAPEX. Wastage is a first-class entry with a reason and a photo, and anything over threshold goes to Approvals before it counts. Cuts and yields, bill passing and escalations live here too.

Campaigns. Guests, segments and journeys — “regular after three visits”, “lapsed after ninety days”, “repeat no-show” — with consent enforced at the outbox rather than on a checkbox. WhatsApp runs against the real Business Cloud API when credentials are present.

Operations. An SOP engine where a daily checklist, an FSSAI audit and a regional store visit are the same object with different settings: 27 input types, weighted scoring, auto-fail items, conditional logic, and evidence carrying GPS, device and duration. Maintenance tickets, compliance records and licence expiries roll into one restaurant health score.

Command Centre and Reports. A daily huddle view per outlet, an inbox of what needs a decision, and a report workbench that exports to CSV, Excel, PDF, PNG and PowerPoint.

Underneath, a Microsoft Dynamics 365 Business Central connector keeps finance in step, a communications hub routes email, SMS, WhatsApp and in-app messages through one outbox with delivery logs, and AUXO Brain answers questions from live rows rather than from a model’s guess — scoped to what the person asking is allowed to see.

The tenancy model

For a multi-tenant product there is exactly one failure that cannot be walked back: one customer seeing another customer’s data. A wrong number in a report is embarrassing and fixable. A cross-tenant read is a disclosure, and no later release un-discloses it.

Most SaaS keeps every customer in shared tables and separates them with WHERE tenant_id = ?. That works precisely as long as every query in the codebase remembers the clause — including the report written three years later by someone who has never heard of the tenancy model. One forgotten WHERE and the product leaks.

AUXO gives every workspace its own physically separate database. Another customer’s rows are not in the file being queried. A query that forgets to filter does not leak — it returns nothing. The mistake is not caught. It is unrepresentable.

The tenant is bound once at the edge of the request in an AsyncLocalStorage scope and read at the bottom by getDb(), rather than threaded through several hundred call sites where a single miss would be silent. On the server, a database access outside any tenant scope throws rather than falling back:

Database access outside a tenant scope. On a multi-tenant server every request must run inside runInTenant(); this is refused rather than served from a shared database.

Refusing is recoverable. Quietly opening a shared database is not. That guard caught a real defect the first time it ran — handler registration was resolving getDb() once at startup, which on a server would have captured the first customer served into every handler’s closure and served their rows to everyone afterwards.

Sessions are HttpOnly cookies, never localStorage. Passwords are scrypt with a unique salt. Sign-in with Google or Microsoft is built in (OpenID Connect with PKCE, tokens verified against the provider’s keys). Account, workspace and membership are re-resolved on every request, so suspending a workspace or removing a member takes effect immediately rather than whenever a session happens to expire. Public sign-up is closed; workspaces are created by invitation.

Deployable three ways — which is a sales advantage

The hosted SaaS is the product. But the same codebase also runs as a desktop application and on a phone, and that matters commercially rather than being a curiosity.

Enterprise buyers in this sector routinely refuse cloud storage of commercial terms and site data. AUXO can answer that: the identical product, running entirely on their own machine, with data never leaving it. Most SaaS competitors have to say no to that customer.

These are not three ports. They share the same handlers, the same schema and the same permission checks, and differ only in how a call travels:

        React interface  ·  identical on every surface
                     │
        ┌────────────┼────────────┐
        │            │            │
     HTTP      Electron IPC   Capacitor
        │            │            │
  per-tenant     local DB     local DB
   SQLite       (on-prem)     (mobile)

Adding a feature adds it everywhere, because there is only one of it.

How it runs in production

The hosted instance lives in Mumbai, behind Cloudflare, on a LiteSpeed Node runtime with a leased scheduler — two processes, one of which holds the lease and runs the outbox, reminders and nightly jobs while the other stands by. Tenant databases are backed up nightly and kept for fourteen days.

Every server exception, slow call and browser error lands in PostHog, and a scheduled AI agent reads the previous day’s failures each morning, fixes what it can, deploys, and reports. The site itself is a Cloudflare Worker; the product is not — a deliberate split, so the marketing page and the customer data never share a runtime.

Where it scales next

Being straight about the current ceiling, because a serious buyer will ask.

The hosted deployment runs as a single machine. Every tenant is a SQLite file on one volume, so a second machine would hold its own copy and the two would diverge. Scaling today means a bigger machine, not more of them.

That is the correct trade at this stage — it is fast, cheap to run, and the isolation guarantee is stronger than what shared-table competitors offer. The path beyond it is known and does not require rewriting the product: the data layer is reached through one function, so moving tenants onto Postgres or libSQL/Turso changes that layer rather than the twenty-five modules above it.

Seeing it

Every screenshot on this page is the live product running on fictional data — an invented group called Meridian Hospitality, its eleven brands, synthetic vendors and generated financials. Nothing here belongs to a real company.

Access is by invitation. Tell me what you want to see and I will set up a workspace with the full 25-outlet portfolio for you to change as you like.

Source

AUXO is closed source. The repository is private, and the server — handlers, schema, permission model, integrations — never leaves the machine it runs on.