← 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 NWCS is fine. Store 5 says NWCS 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 Wenatchee and another way in Spokane. 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

Two LLCs is two payroll runs is two W-2 batches is two W-3s.

Form 941 quarterly, W-2 batch, W-3, 940 FUTA, WA L&I + PFML + SUI — done twice, by hand, often by the bookkeeper at 11pm on the 30th. Everyone treats it as the cost of being multi-location. It’s not.

04

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.

05

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 model, six stores, vendor reliability scored on the row.

AI-drafted POs read 30/60/90-day velocity per store, vendor reliability across the chain (✓ 92% / ⚠ 78%), and fill-rate against the last six POs with that brand. Your purchasers stop comparing notes — the model does it for them, and the brand rep can see the same scorecard you can.

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

WAC 314-55-095 industry discount has a 90-day re-verify enforced at every register, not on a clipboard per store. Waste log witness sign-off (314-55-079) is a workflow, not six different PDFs. Vendor-license lapses (314-55-035) auto-pause receiving — chain-wide.

Two LLCs, one platform, payroll that actually closes on time.

Entity A and Entity B run Form 941, W-2 batch, W-3, 940 FUTA, and the WA L&I + PFML + SUI quarterly trio in the same login the closer uses. Per-LLC separation is built in — the bookkeeper picks the entity from a dropdown, not a different platform.

Variance climbs a ladder, not a phone tree.

Per-budtender till sessions, $0–$10 logs, $10–$50 manager review, $50+ unoffset two days pulls camera footage. Stale-open drawers surface on the health board the next morning, chain-wide. Saturday Loomis 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, cron jobs that didn’t run last night, sibling-store probe results. The page Doug checks before he opens email — and the page a new GM learns the chain from.

What ships in the codebase today.

01 · what the product does

Multi-LLC payroll separation built in (Entity A + Entity B, same platform, separate Postgres)

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 WSLCB license, with the same workflow across all of them — so a parent LLC manages multiple stores without a separate tenant per vendor. Cross-store reporting and cost-aware tiers are part of the Multi tier; cross-state federation is Enterprise.
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. Cannabis cash-margin is tight enough without a vendor metering you on every staff add. Card-processing fees, if you turn them on, pass through at processor cost; we don’t take a per-swipe markup.
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. On the Enterprise tier, source-code escrow is available so the platform itself keeps running on your terms if anything ever happens to us. 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, the per-LLC payroll, and the chain-wide health board.

Request a demo
Request a demo
30 min · demo login emailed in ~60 sec · no call required