Your menu, on your domain, with stock from the POS you already run.

• 01 · STOCK TRUTH

  Every item shows where its stock count came from and how old it is.

  Each product badge names its source, POS or Metrc, and its sync age. When a sync goes stale, the item reads "stock unconfirmed", add-to-cart switches off and the shopper gets a call-or-walk-in link instead. Items are hidden when stock runs low, with a buffer held back for in-store sales during the sync gap. A store can tighten these thresholds but never loosen them.

• 02 · POTENCY BY PACKAGE

  Potency and the COA come from the package's lab result, not a catalog.

  Values are read from the Metrc lab result tied to the package label. When one SKU spans several live packages, the card shows the range and a COA link for each. A package with no passing lab result is hidden. A SKU that can't be mapped to a single package shows no potency and is flagged for the menu manager.

• 03 · ORDER HANDOFF

  Online orders land in your POS, and the shopper is told the truth about them.

  Where the POS accepts orders through its API, BudAlly sends the order there. Otherwise staff get a pick list by package label and key a short order code into the POS ticket; the code carries a check digit, so a typo can't match the wrong order. The shopper sees "sent to the store's POS" or "request · confirmed by store", never "reserved" unless the POS itself holds the stock. Pay at pickup is the default.

• 04 · RECONCILIATION

  Every order is matched to a POS receipt and a Metrc sale.

  Matching runs first on the POS order id, then on the order code, then on a strict rule covering customer, time window, packages and subtotal. If more than one receipt qualifies, the order goes to a manual queue and is never picked automatically. Price, tax or substitution drift is flagged with its reason, and a receipt with no Metrc sale after 24 hours becomes a compliance alert.

• 05 · COPY AND COMPLIANCE

  Menu copy is checked against your state's rule pack before it publishes.

  The age gate, required license and warning text, medical and adult-use separation, discount wording and a banned-claims linter all run per state. The linter covers POS and brand descriptions, not only BudAlly's own text. Flagged copy goes to advertising review and nothing publishes without sign-off. A rule the pack doesn't hold returns UNKNOWN and goes to a person.

• 06 · PRICE AND LIMITS

  The menu shows your POS price, with taxes broken out in the cart.

  Prices are the POS price for that menu, medical or adult-use, and the cart shows a line-level tax breakdown. Prices come from the POS; a price change is drafted, approved by a named person and only then sent to the POS where it allows it. The purchase-limit meter is always labelled an estimate, because the POS confirms limits and tax when the order is created. A mismatch at the POS quote shows up as drift before the order is sent.

• 07 · APPS

  One set of theme tokens drives the web menu, the PWA and the iOS app.

  Logo, colours, fonts, legal name and license number are set once per store, and a contrast check blocks publishing a theme that fails. Android and web shoppers get an installable PWA with web push. A single BudAlly iOS app lists the stores a shopper has joined and stores nearby, sorted by distance, and allows ordering only from inside the store's state. A chain that wants its own branded iOS app publishes it from its own Apple Developer account using BudAlly's build pipeline.

• 08 · YOUR DOMAIN

  The menu runs on your domain, and hours are edited in one place.

  The menu is served on your domain through a CNAME, and the domain stays in your registrar account; BudAlly never registers it. Server rendering, structured data, a sitemap and a 301 map from old menu URLs come with it. Hours, holiday closures and the menu URL are edited once and pushed to Google Business Profile; products and prices stay on your own domain and app. Conflicts are shown to you, never silently overwritten.

Questions