The directory lists places to stay where guests are allowed to smoke cannabis. Each listing answers one question: where on this property can I smoke?
For weeks I treated that question the way I treat most data problems. Find the source, quote it, record when you checked, and flag anything uncertain. By the end, every listing was defensible. A typical one read like this:
Verified from the Vrbo listing (checked 6 October 2026). The host writes: "420 friendly OUTSIDE ONLY — please note any smoking of any kind inside may result in a minimum $250 fine." A whole-home or private-suite rental is not a hotel, so the host's rules apply; street address is released after booking.
Every word of that is true. Then the person I build this for photographed their screen and sent it to me. A hotel card, three-quarters legal text: the state code section, a "legal grey zone", "ask the front desk before you rely on it", a $500 cleaning fee. The message was blunt. "You make it so scary that users might even end up not booking."
They were right, and it took me a while to see why.
Accurate and welcoming are different questions
Accuracy decides what you're allowed to say. It says nothing about what the reader needs to see first.
Someone looking at a rental they might book wants three things: is it allowed, where, and is there anything I must know to avoid a problem. The note above answers all three, but it buries them under how I know: the source, the check date, the legal category, the address policy. That part was written for me, not for the guest. It's audit material, and I'd published it.
The result read like a warning label on something I was meant to be recommending. A fee quoted on a listing card doesn't say "here's a detail". It says "people get charged here". A "grey zone" doesn't inform anyone. It makes them nervous. None of it was false. All of it was the wrong thing to lead with.
The fix: evidence and copy live in different places
The rule I settled on:
- The page shows the rule, in plain words. "Cannabis is welcome outside, on the deck or the front porch. No smoking indoors."
- The record keeps the proof. The source, the quote word for word, the date, who checked. That's where I go when something needs auditing. It doesn't need to be on screen for a guest to trust it.
The same note, after:
420 friendly outside. No smoking inside.
I kept every fact a guest needs: indoors or outdoors, where exactly, age limits (one property requires the main guest to be 25+, and that stays because it can get someone turned away at check-in). I dropped everything that was there to protect me: check dates, "verified from", fee amounts, and "ask the host" wherever we already knew the answer.
Rewritten that way, 105 listings went from a paragraph each to a line or two. The listing pages themselves went from showing the full note under every card to one short line per stay, with the detail page one tap away.
The opposite failure was in the same template
While I was cleaning one page, I found that an older template on it had been doing the reverse. It wasn't over-cautious. It was over-selling:
- a "Selling Fast" box claiming one town was "92% booked for upcoming weekends";
- a "#1 Reader's Choice" badge on whichever listing loaded first, on a site with no reader votes;
- a "Risk Level: ZERO" badge on the top two cards and "LOW" on the rest, decided by position in the list;
- a sidebar promise that "we verify policies monthly", which nothing did.
None of it came from data. It was invented reassurance, and it sat a few inches from my over-sourced caveats. Two opposite mistakes, one page: one made true things sound frightening, the other made untrue things sound safe.
Both come from the same place: writing for the wrong reader. The caveats were written for an imagined auditor, and the fake badges for an imagined conversion-rate chart. Neither was written for the person deciding where to sleep.
All four came out. Nothing replaced them, because the honest version of "92% booked" is no claim at all.
A default can speak too
One more version of the same problem was hiding in the data, not the copy.
Each listing has amenity flags (smoking, vaping, edibles) and the detail page renders them as tiles. A flag set to false shows as a red "Not Permitted". Many listings had vaping and edibles set to false. Not because anyone said no, but because nobody had asked, and false was the value that got typed in.
So a place whose host said "cannabis is welcome anywhere outside" showed two red "Not Permitted" tiles under the welcome. The person I build for made the point simply: if smoking is allowed, vaping and edibles obviously are. They're the quieter, odourless versions of the same thing. That's now the rule, and it applies to every listing where smoking is allowed.
The general lesson is the one I keep relearning: an unknown stored as false doesn't stay unknown. On the page, it turns into a claim.
What I don't know yet
Nobody had booked through the directory in weeks, which is part of why this mattered. I'm not going to claim the rewrite fixed that. The honest test is in two weeks: what share of visitors clicked through to a booking page before the change, and what share after. If friendlier pages help, that number should move before any booking does.
What I can say now is narrower. A page can be fully sourced and still fail the reader, because sourcing answers "can I defend this?" and the reader is asking "should I book this?". Keep the first answer in the record. Put the second on the page.
Top comments (4)
The "allowed to say vs. need to see first" distinction is the sharpest formulation of a lesson I keep learning as a technical writer. I once front-loaded API documentation with provenance — which RFC defined the endpoint, which version introduced it, who signed off — and readers skipped the whole page, because the one sentence they actually needed ("pass this header and it works") was buried under the evidence. The fix was your rule, almost verbatim: the page carries the answer in plain words, the changelog and footnotes carry the proof. One detail I would add: the "unknown stored as false" failure generalizes beyond amenity flags. In docs, a parameter with no documented default quietly becomes "has no default" in the reader's head, which is the same false claim wearing a different hat. Have you considered a third state for the amenity tiles — something like "Unverified" — instead of forcing every unknown into true or false?
Yes, and it already has one. The tiles have three states now: a green "allowed" when the host's rule covers it, a grey "Unconfirmed" when nobody has told us, and a red "Not Permitted" only when the property has actually said no. Red used to be what you got by default. Now it has to be earned by a real answer.
The undocumented-default point is a good one. Leaving a gap doesn't keep you neutral, because the reader fills it in, and they usually fill it in with the worst case. Grey is mostly there to stop that from happening.
The part I'm still working on is how many listings sit in grey. "Unconfirmed" is honest, but if half a page is grey it reads as hesitant. So the real fix is asking more hosts, not finding a better label.
Three states with green as 'allowed when the host's rule applies' is already ahead of most listing pages I've seen. On the grey-half problem: 'Unconfirmed' reads as a verdict about the listing, when the honest statement is about you — 'not yet verified' puts the incompleteness on the process, not the host. If half the list sits grey, though, the label won't save it — the real question is whether verification can be batched cheaply enough to drain the grey faster than listings arrive. What's verification costing you per listing right now?
"Written for me, not for the guest" is the sentence that separates the two failures, and it generalizes past listings. Most teams have one page somewhere that is really an audit trail wearing a customer-facing costume: status pages full of internal incident codes, onboarding docs that lead with liability text, renewal emails that quote the contract clause before the price. Your fix, evidence in the record and plain words on the page, is the right split, and the tell for finding the next offender is the same one your user gave you: read the page as the person it is for, and anything that makes you hesitate is audit material that escaped.