Five vendors, one bookkeeper, one receivership notice. Consolidate before the buyer asks why.

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.

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.

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. Cross-store reporting and cost-aware tiers are part of the Multi tier; cross-state federation is Enterprise.

A typical switch takes about four weeks; your dates are set in a written scope, because it depends on how clean the data in your current system is and on what is ready in your state. The cutover itself is planned overnight — last close on the old system Sunday evening, first open on CannAgent Monday morning. The ramp before that is data audit, hardware swap, and three days of on-floor support during the first week. Multi-location chains stage cutovers one store at a time; we don’t flip ten registers at once. The shape is the same whichever system you are coming off — what changes is how much of your history your outgoing vendor lets you export, which is the first thing we check.