← All use casesMulti-location chains, 6+ stores

Six stores, six spreadsheets, one owner who can’t sleep.

If you run six-plus stores on a register that doesn’t know your other five, the back office is held together by you and a phone tree.

The pains your operator group already knows.

01

Vendor reliability is anecdotal until you reconcile six POs by hand.

Store 3 says a vendor is fine. Store 5 says the same vendor missed last Tuesday. Nobody pulls the fill-rate scorecard because the scorecard doesn’t exist — your purchasers each keep their own version in a Google Sheet, and the brand reps know it.

02

Cross-store data drifts because the registers don’t share a brain.

A SKU is mapped one way in Denver and another way in Pueblo. Loyalty members show up at a sister store and the budtender can’t see their tier. The chain reads like six independents that happen to share a logo.

03

Cash at scale is where the shrink hides.

Six tills, six closes, six Loomis pickups a week. Variance under $20 doesn’t even get logged. By the time you find the pattern, the budtender who was running it has moved to another store.

04

On-call escalation is your phone or nothing.

A register goes down at 7:48pm on a Friday in store 4. The closer texts the GM, the GM texts you, you text the vendor’s support inbox, and three of the six stores are now 90 minutes behind because nobody else knew it happened.

What the modules actually do for you.

One reorder formula, six stores, each vendor’s fill rate in the quantity.

Suggested quantities read each store’s 30-day sales rate, the vendor’s lead time, and what each brand actually delivered across your resolved POs. Your purchasers stop comparing notes — the vendor scorecard shows fill rate, lead time and partial fills over 30 to 365 days for everyone.

Compliance enforced in code, not in a six-store binder.

WAC 314-55-096(1)(j)(vi) caps trade samples at 30 units to any one employee per calendar quarter, counted at every register rather than on a clipboard per store. The waste form's named witness is a workflow, not six different PDFs. Vendor license expiry is one field on one vendor record, read the same way at every store — one list, not six spreadsheets that disagree about which license expired.

Variance climbs a ladder, not a phone tree.

Per-budtender till sessions. A small variance gets a note, a bigger one gets a manager review, and one that is not offset within a couple of days escalates again. Stale-open drawers surface on the health board the next morning, chain-wide. Saturday armored-car pickups reconcile cleanly because the bag-tag photo is in the same row as the cash-out total.

One green-board for all six stores. Yellow before red.

Health-board tiles per location: stale till sessions, overdue write-up follow-ups, vendor-license lapses, overnight jobs that did not run. The page an owner checks before opening email — and the page a new GM learns the chain from.

What ships in the codebase today.

01 · what the product does

Each location runs on its own database — its books stay its own, on the same platform

02 · what the product does

Vendor reliability scored across every store on every PO row

03 · what the product does

150+ in-app help panels so a new GM solves their question instead of texting you

What this kind of shop usually asks first.

Can we run multiple stores under one parent LLC on the same platform?
Yes. Each location runs on its own Postgres database under its own state license, with the same workflow across all of them — so a parent LLC manages multiple stores without a separate tenant per vendor. Each location carries one base plus the add-ons it runs. Cross-store reporting and cross-state setups are scoped in your quote.
Is there a per-staff or per-transaction fee?
No. Pricing is per location, billed monthly. Add a register, add a budtender, add a manager — same line on the bill. The one exception is the Payroll Portal, priced per employee on payroll, and it is not offered to new stores yet. Cannabis cash-margin is tight enough without a vendor metering you on every staff add. There is no card processing today, so there are no card fees from us.
What happens if your servers go down — does our register?
Each location runs on its own Postgres database hosted on Neon, with the application served from Vercel’s edge. The register has an offline cache for the last-known cart state, so an in-flight transaction completes even if the connection blips. A full regional outage on either provider would degrade the back office (analytics, reorder queue) before the register; we’ve held that as the design boundary from the start, because the register is the one surface a sale can’t wait on.
Who owns our customer and transaction data?
You do. Always. Each location runs on its own Postgres database, exportable any time in standard SQL. No vendor-database lock-in. Your customer list is not aggregated, not resold, and not used to train any model — it sits in your database.

If your sixth store hasn’t made the back office easier, the platform is the problem.

The demo walks the cross-store reorder and the chain-wide health board.

Request a demo
30 minutes. Demo login usually next business day.