01 · Start here · Independent case study · 2026-09-28 · Not commissioned or endorsed by Puff Cannabis
The sign says 2/$25. The receipt says ?
“The site says 2/$25 disposables. Which ones, at my store — and is $25 what I'll actually pay?” Puff publishes deals on one surface and products on another. This follows that one customer question across both, builds the join that is missing, and shows the work that would keep it honest.
One question, followed all the way through the work the role owns.
I'm Mousa Batarseh, a webmaster and e-commerce specialist in Warren, Michigan. I have spent more than five years building and running storefronts and the catalogs behind them: site architecture, catalog migrations of more than 14,000 SKUs, promotional calendars, and the QA that keeps a launch from embarrassing a store.
This is independent work. Nobody at Puff Cannabis asked for it, reviewed it, or knows it exists. It is not a redesign, it does not touch a live system, and it does not claim a business result. What it is: a worked answer to one question a Puff customer could reasonably ask, built from pages anyone can open.
The site gives Puff real credit. The storefront is a native, first-party build on the company's own domain, not a third-party embed. Product pages publish price, size, brand and availability per store in structured data. There are eleven open locations with real store-scoped URLs, a working category taxonomy, a brand directory, ten effect labels, a loyalty programme and a public FAQ that already states the Michigan purchase limits. The traffic strategy — deals on the home page — is sound.
The gap is narrower than "the site needs fixing", and more interesting. The promotion layer and the product layer are both real and both populated. They are simply not joined. A deal card knows its title; the catalog knows the price. Nobody puts the two in the same sentence, so the customer does the arithmetic in the aisle.
Where to start
If you have four minutes, take the walkthrough. If you have twenty, open thedeal checker and search for a real offer, then open the reconciliation workspace and fix one thing — the effect of that fix carries through to the checker and the export.
What was actually found
Counts, not adjectives.
These are counted from the records in this case study, which were read off public pages on 2026-09-28. They describe the sample and the published pages — not Puff's business, and not its customers.
Deal cards observed
30
16 on the home page only · 10 on the specials index only · 2 on both
Deals with a location scope
0
out of 28 unique offers. Two home-page cards carry a store prefix; it is never expanded.
Deals with a date
0
“Limited time offer” is the closest thing to a validity window anywhere in the set.
Deals resolving to a product
24
of 28, on the modelled sample. The rest name too little to look up.
The company's own wording“*Website cart may not reflect the bundled price but it will be adjusted at time of payment.”/specials/2-25-disposables/ · retrieved 2026-09-28
What that means hereThe company has already recognised the gap and mitigated it with a disclaimer. This case study does not claim the cart is wrong. It claims the join that would make the disclaimer unnecessary has not been built, and that all the data for it already exists.
Choosing what to work on
Three plausible opportunities. One was worth building.
Each was tested against evidence strength, business relevance, relevance to the role, feasibility and how much a reviewer could actually inspect. The reasons for rejecting two matter as much as the reason for choosing one.
ADeal-to-menu reconciliation
Chosen
Does the offer a customer saw on a card resolve to products they can actually buy, at their store, at that price?
Evidence strength
Strong. 28 published deal cards observed; none carries a location scope, a date, or a list of eligible products. The company's own deal pages publish a cart-price disclaimer.
Business relevance
High. Deals are the home page's entire merchandising strategy.
Relevance to the role
High. This is promotion QA plus product data plus landing-page QA.
Feasibility here
High. Runs entirely on published data.
Demonstration
A resolver in the storefront and a reconciliation workspace behind it.
BEffect-led product discovery
Not chosen
Can a shopper who says "something for sleep that isn't too strong" be answered without a budtender?
Evidence strength
Moderate. Ten effect terms already exist and work, and strain pages exist. What is not observable is the rule that assigns a product to an effect.
Business relevance
Medium. It serves a shopper who is already on the site.
Relevance to the role
Medium. Discovery work, less operational work.
Feasibility here
Low-medium. Without the assignment rule, any recommendation would be invented.
Demonstration
A guided shortlist builder.
Rejected, not because it is a bad idea but because the rule behind it is unobservable from outside. Building it would mean inventing the thing it recommends on. It also repeats the shape of the reference project's discovery tool rather than answering this company's actual gap.
CMenu data hygiene
Not chosen
How complete and consistent is the product record behind the menu?
Evidence strength
Weak from outside. Product pages publish brand, size, price and availability, but measuring completeness at 29,000 store-scoped URLs means a crawl, and the interesting failures live behind the admin.
Business relevance
Medium. Real, but a subset of A.
Relevance to the role
Medium.
Feasibility here
Low. It needs scale access to say anything defensible.
Demonstration
A completeness dashboard.
Kept as a supporting issue rather than the centre. It is the layer that makes A possible, so it appears inside the reconciliation workspace and the checks, without being the headline.
What would change the recommendationIf the ordering platform already applies bundle pricing correctly at every store, and if the stores already receive store-scoped promotion briefs, then the operational half of this case study is unnecessary and the remaining work is presentational: say the scope, say the dates, show the eligible products. I would rather find that out in week one than build around it. That question is the first thing in the 30-day plan.
The chain
Every page is a step in one argument.
Nothing here is a standalone dashboard. Each step takes the output of the one before it, and the same records are read all the way down.
What is observed, modelled, or still needs company data
—
First 30, 60 and 90 days
What I would do first if this were the job.
Written as a plan, not a promise. The first month is deliberately about learning the handoff rather than shipping, because the most useful thing I could find out is that part of this case study is wrong.
30Learn before changing anything
60One improvement, with the check that keeps it
90Measure one agreed test
Day 01–30
First 30 days
Learn before changing anything
Walk the store-to-store promotion handoff: who writes a deal, who publishes it, who tells the stores, who fixes it when it is wrong.
Get read access to the ordering platform and the promotion records, and reconcile the two by hand for two weeks.
Sit with the metrics that already exist: search terms, zero-result rate, cart adjustments. Do not add tracking yet.
Write down the definitions of the five metrics on the measurement page and get a human to agree with them.
Day 30–60
Days 30–60
One improvement, with the check that keeps it
Publish promotions as records — scope, dates, terms, eligible products — behind the existing templates so nothing looks different on day one.
Ship the two cheapest consumer-facing wins first: location scope on the card and a date on the offer.
Add the readiness check as a gate a promotion passes before it goes live, not as a report nobody reads afterwards.
Track the first four weeks of resolve rate by store, and read it with the stores rather than about them.
Day 60–90
Days 60–90
Measure one agreed test
Run the store-alternating test on deal-to-product continuation, with the guardrail metrics fixed in advance.
Retire or rewrite the cart disclaimer only if the cart and the card actually agree.
Hand the recurring work to the people who own it — a checklist with an owner, not a dashboard with a viewer.
Report read, not up: state the interval, the assumptions and what would change the recommendation.
About my experienceThe employers, job titles and numbers about my own past work, like the 14,000-item catalog, come from my résumé. They describe what I have done before. They are not results measured in this case study.
Why this problem is the one I picked
Most of my working life has been about the seam between what a website says and what a store does. I have run promotions on a multi-location retail calendar, built the landing pages and the sales forms, and cleaned up a catalog of more than 14,000 items so that a price on a page and a price in the till were the same number.
Two pieces of my own work sit directly underneath this one. The Deals Operating System puts a promotion through sixteen checks before it reaches a menu. A set of independent cannabis reviews did the same for three Michigan operators — comparing menus, store records and pages, and tracing a promotion from a hero banner to a landing page to a cart rule. Both found that the interesting failures are almost never in the design. They are in the join between two systems that are each working as designed.
This case study is the same method pointed at a company I have not worked for, with the evidence labelled so a reviewer can check it rather than take my word for it.