Cannabis Dispensary Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a dispensary software project turn into a full point of sale (POS) replacement?

The brief that arrives is almost always narrow. Somebody wants the METRC reconciliation to stop eating Sunday nights, or wants purchase limits enforced across all six stores. Twelve weeks later the scope has grown a register interface, a cash drawer driver, a label printer and an offline mode, because every one of those turned out to be attached to the thing that was actually asked for.

This is specific to cannabis retail because the point of sale is not a separate system from compliance. In grocery you can bolt an analytics layer onto a till and the till carries on. Here the receipt is the compliance event. The moment you decide your own inventory ledger is the source of truth, you have taken responsibility for what the register writes, and the register is now yours to build, support and keep running when the internet drops.

The fix is to decide the boundary in writing before any code exists, and to pick one of two shapes deliberately. Either you keep Dutchie, Flowhub, Treez or Cova at the counter and build a compliance layer that reads from it, reconciles against METRC and enforces limits through a companion screen at the door, or you replace the register outright and accept the hardware, offline and conflict resolution scope that comes with it. The builds that fail are the ones that started as the first shape and drifted into the second without anyone renegotiating budget or date.

What goes wrong when you migrate three years of sales history and package tags?

Migration off an incumbent point of sale is treated as a data export in the estimate and turns out to be a two to three week workstream in reality. The reason is the tag. A METRC package tag is the join key that lets a historical audit resolve against state records, and if it does not survive the move, every sale before cutover becomes an orphan you cannot defend.

Three things break in practice. Partially depleted deli jars have an on hand figure in the old system that nobody physically verified, so you inherit a variance on day one and it looks like the new system caused it. Loyalty balances and customer records carry duplicate identities, because online ordering created one person and the in store identity scan created another, and merging them after go live means merging their purchase histories too, which is exactly the data your daily limit ledger depends on. And open transfers sitting in an accepted but not received state at cutover belong to neither system.

The fix is unglamorous. Preserve the tag as the join key on every historical row. Run both systems in parallel with a daily diff and only cut over after the diff is clean for five straight days. Do a physical count of every open jar at cutover and record it as an adjustment with a reason before the new ledger opens, so the variance is dated and explained rather than discovered. Sequence stores one at a time. A bad cutover during a Friday rush is a revenue event, not a support ticket.

Why do the menu, loyalty and payment integrations break after launch?

They break because most of them are batch pushes rather than reads against a shared balance. Dutchie Ecommerce, Jane, Weedmaps and Leafly all pull inventory on a schedule. Between syncs your last two carts sell at the counter and three online orders come in for them. The pickup desk tells three customers no, and one of them writes the review. Alpine IQ or springbig fires a promotion against a segment built from yesterday's data. Aeropay, Dutchie Pay or CanPay settles on its own rhythm and the reconciliation lands somewhere else entirely.

The industry specific part is that nothing reserves anything. On hand is a number pushed outward every few minutes rather than a balance with holds against it, which is tolerable when one channel sells and untenable when four do. Add per channel pricing and the same product now has four prices maintained in four places.

The fix is one inventory service where on hand minus reserved equals available, reservations created at cart with a time to live and released on abandonment, and every channel reading the same available number from an event stream rather than a scheduled export. Per channel price and availability become configuration on one record. Then, and only then, add the intelligence that pays for itself: demand forecasting on flower trained on your own sales by batch, weekday and promotion history, which tells purchasing on Monday which lines go out of stock by Thursday and which flower is aging past the point where it sells at full price.

What happens when purchase limits are not enforced across every store?

A customer buys their daily limit at your first store at noon and buys again at your second store at six. Both carts were legal. The person was not. Your point of sale enforced the cart in front of it, because that is what a single store product is built to do, and your exposure is now a regulator asking how you enforce a per person per day rule when your systems only understand a per transaction rule.

It gets harder because limits are expressed in equivalency, not units. California adult use runs 28.5 grams of flower and 8 grams of concentrate. Illinois gives residents 30 grams of flower and 5 grams of concentrate and halves that for non residents. Colorado runs a one ounce flower equivalency where an edible eats the same bucket. Medical cards carry their own profile and their own expiry. A budtender cannot compute that mentally with a queue behind them.

The fix is a single rolling daily equivalency ledger shared by every location, keyed on an identity resolved at the door from the identity scan and stored as a hashed key rather than the raw document, never in a URL. The budtender sees remaining headroom in grams equivalent before the item enters the cart. The rules themselves live in a versioned policy table with effective dates so an operations lead changes a state on the day the rule changes rather than waiting for a deploy. Every check is logged, so when the state asks how you enforce, you show a ledger instead of a policy document.

Should you build custom or configure what you already own?

Configure, genuinely, if you run one to three stores in a single state, sell packaged product and prepackaged eighths, do no delivery and your revenue is under roughly six million dollars. Dutchie, Flowhub, Treez and Cova are real products built by people who understand this industry, and at that size the per store subscription is cheaper than one engineer. Most of the pain at that scale is process, not software. Anyone recommending a build at three stores is selling you something.

Before you commission anything, exhaust the configuration you already paid for. Turn on the exception reporting your vendor ships, even if it is weak. Standardise how deli jars are received and weighed, because a tare discipline problem does not become a software problem just because you write software. Consolidate to one traceability system per state rather than tolerating a second because one acquisition used it.

Build when the signals stack: five or more locations or a second state, more than one full time person on reconciliation, deli style weighing at volume, a delivery operation, or vertical integration where cultivation, manufacturing and retail all touch the same packages. The clearest signal is roadmap. You asked your vendor for cross store limit enforcement or a workable exception queue, they said it was on the roadmap, and it has been on the roadmap for four quarters. At that point you are paying a subscription to wait.

How do hidden costs get into the quote?

Not through dishonesty. Through categories that look like configuration and are actually integration. In Digital Heroes delivery experience the recurring ones in this category are consistent enough to list.

• A second traceability system. BioTrack in some markets and Leaf Data Systems in Washington are separate integrations, not a configuration flag on the METRC one.
• Offline mode at the register. You need it, because stores lose internet and cannot legally stop selling, and conflict resolution against a state ledger is genuinely difficult engineering rather than a caching decision.
• Hardware drivers. Label printers, scales and cash drawers each carry their own driver, their own firmware generation and their own failure behaviour.
• Each payment rail. Every processor is its own settlement file, status vocabulary and reconciliation job.
• Historical migration. Usually a two to three week workstream by itself, and almost always quoted as an afternoon.

The fix is to make the developer price these as named line items before kickoff rather than as a contingency. Ask which of them are in the number and which are excluded. A partner who has shipped this will volunteer the list without being asked, because they have been caught by it.

What separates a dispensary build that works from one that fails?

Four tests, and they separate the field quickly. Make them draw the data model on the call and ask how packages, items, batches, lots and stock keeping units relate, and where the tag lives. If they conflate a METRC package with a product record, they have never shipped this, and that single mistake costs a rebuild.

Ask what the system does when METRC returns an error at six on a Friday. The right answer involves idempotency keys per receipt, a durable outbox, exponential backoff and a human facing exception queue with the original cart, budtender, register and timestamp attached. The wrong answer is that they retry.

Ask where the rules live. Jurisdiction limits, tax ordering and rounding belong in versioned data your compliance lead can edit, with effective dates and a harness that replays last quarter's receipts against a proposed change so you can see the exposure before flipping it. If a rule change needs a sprint, you have bought a liability.

Then settle ownership in writing before kickoff. You should hold the repository, the cloud accounts and the right to bring in another firm at any point. Compliance systems outlive vendor relationships, and the whole reason you left the off the shelf tool was to stop waiting on somebody else's release schedule.