A Virtual Budtender Built on Your Menu's Own Lab Numbers

The five tap-only questions cover the shopper's goal, how they like to take it, how strong, what they are spending, and any aroma they lean towards. Only the goal is required, and a shopper can skip to the picks from the second question onward.

The answer buttons come from the shelf. There is no free-text box, and the widget offers only the categories and aroma groups the current shelf can honor.

Each pick links to that product on the live menu and discloses how the pick was scored, so the shopper reads the reasoning and then buys on the store's own menu.

The matching is a fixed calculation, so the same answers always return the same three products from the same menu snapshot. Ties are broken by price.

A result card follows three rules:

• Lab values or nothing. Cards show only lab values reported on the live menu. We drop a product with no reported chemistry rather than guessing at it.
• Strength is relative to the category. Potency fit is a percentile inside the product's own category, so one strength answer means something sensible for flower and for a concentrate at once.
• Edibles by the piece. We rank edibles on milligrams per piece, never the package total.

The label matters less than what makes the choice. In ours, no language model chooses or words a recommendation. The fixed calculation above does both, so a store manager can check any pick against the menu line by line.

The widget draws itself in the shopper's browser. Google renders JavaScript pages in a queue after crawling, and its own JavaScript SEO guidance says server-side or pre-rendering is still a great idea, so the text we want read sits on a companion page.

The companion page is a real page at its own address, carrying the tool inline plus text that loads with the page: a lead answer, what each question asks and why, the terpenes the client's menus report, visible FAQ answers and the legal line. Those FAQ answers render visible and uncollapsed, and the schema mirrors the visible text.

Making the menu itself readable to crawlers is a separate job, handled by Apex MenuEdge, which we deploy and run for Dutchie-powered menus.

We assess the menu platform and harvest the lab data, then install the engine and check the harvested data before anything is styled.

The visible work follows: we brand the widget with the client's own logomark and design tokens, write the companion page, and wire up the launcher, a footer link and the sitemap entry. Before launch we run our release checks, deploy, and run the same checks again against the live site.

After launch, the lab snapshot is refreshed on a schedule inside the client's existing menu workflow, and the checks run before each refresh is committed.

The budtender is one component of a dispensary site. The rest of the site is the work of our dispensary web design and CRO service.

It still ships, in a degraded mode. Lab coverage is a property of each store's own menu data, so we measure whether your menu reports lab panels first. Without them, the aroma question is dropped, matching uses the reported effect profile, strain type, THC and CBD and price, and the interface says the menu does not publish full lab panels.

Like every engagement we take on, it is quoted after an audit. To start, request the free dispensary audit, which runs an automated scan of more than 40 signals and shows the report card on screen. Our client portfolio holds 30 public client case files if you want to see the wider build work first.