How claims are sourced

Where the numbers come from.

Every claim on this site — food-cost ranges, page-speed thresholds, schema requirements, what Google does or doesn’t do — is sourced. Most are dated. The ones that aren’t should be; if you spot one, tell Don and it’ll get added.

Three classes of claim

  1. External-research claims — "Most mobile visitors bounce from pages slower than three seconds." Cited inline with a link to the primary source (Google web.dev research, Nielsen Norman Group, Baymard Institute). Dated by the source page’s own publication date.
  2. Operating-floor claims — “DoorDash takes 30% in our markets.” Sourced from public platform merchant documentation (DoorDash, Uber Eats, Grubhub partner pricing pages) and from Don’s restaurant-floor experience as a manager at Tacombi in Bethesda. Where a claim depends on operator experience rather than a published source, the article labels it as such; where it can be checked against a public source, the source is cited inline.
  3. Studio claims — "Two builds active at a time. Reply within 4 hours." These describe how the studio operates today; they appear in the footer and on /about/, and they’re reviewed quarterly. If you see one that’s out of date, the changelog is where the correction lands.

External research, by domain

For each domain the studio writes about, the canonical sources we cite:

  • Web performance & Core Web Vitals. Google web.dev, the Lighthouse documentation, the Chrome UX Report for real-world percentile data. Reviewed quarterly; see the per-research summaries at /learn/research/.
  • Schema.org & structured data. The schema.org spec for vocabulary, Google Search Central for what Google’s indexers actually use. Tested with Google’s Rich Results Test before publishing.
  • Restaurant operations economics. The National Restaurant Association annual reports, Don’s ServSafe / RAM / MC ABS coursework, and 14 years of operating-floor experience listed in the timeline on /about/.
  • Local SEO & Google Business Profile. Google Business Profile help docs, the public GBP API documentation, and direct testing on the studio’s own listings + client engagements. Where Google’s policy changes (post retention, verification methods), we date the article and the HowTo schema together.
  • Accessibility. WCAG 2.2 AA as the explicit target (named in /accessibility.html). axe-core for automated checks, manual keyboard + NVDA / VoiceOver testing.
  • Reservations & conversion research. Nielsen Norman Group’s local-business research, Baymard Institute’s cart-abandonment studies, Think with Google’s mobile-conversion datasets.

Operating-economics sources

The library uses these public sources for the operating-economics claims that aren’t covered by external research:

Where an article presents an illustrative range rather than a measured figure (the 30-day delisting playbook is one example), the prose names it as such. Operator experience informs the framing of these pieces; specific dollar figures and percentages are either cited or labeled illustrative.

Dating policy

Every article carries datePublished and dateModified in its JSON-LD. Article meta lists the visible reading-time and date. When a substantive claim changes (Google’s policy moves, the studio’s capacity changes, a new credential lands), the dateModified bumps and the change shows up in the /changelog/.

Glossary terms are stamped with a verified date — visible at the top of each term — that re-asserts on the next quarterly review. The 22 most volatile terms (Google policy, Lighthouse versioning, GBP behavior) are date-checked on a 90-day cadence; the rest stamp on their first-commit date.

Corrections

Spot a claim that’s wrong, stale, or unsourced? don@muntin.digital or The Window with topic=corrections. Corrections get the same 24-hour reply turnaround as security reports and surface in the changelog alongside the fix.

The voice contract

The studio’s tone is a contract, not a feeling. Five lines — copied across every brief, every freelance handoff, and the first hire’s onboarding. If a draft (mine, an editor’s, or a model’s) breaks any of these, it gets rewritten before it ships.

  1. POV. First-person singular (“I”), one human, named Don when context warrants. Muntin Digital is the storefront, never the speaker. No royal “we.”
  2. Register. Calm, exact, mid-formal. The voice of a manager doing the math on the back of a check, not a designer presenting a deck.
  3. Sentence shape. Short declaratives. One mid-sentence em-dash maximum. End on a noun, not a verb.
  4. Vocabulary. Restaurant-floor verbs and web-craft nouns, used literally. No abstractions.
  5. Never. No marketing-speak. No exclamation marks. No emoji. No “we” pretending to be a team. No rhetorical questions in headlines. No metaphor outside the window/muntin family.

Banned words (audit and strip)

solutions · leverage · synergize · best-in-class · growth-hack · world-class · robust · scalable · end-to-end · unleash · unlock · empower · ecosystem · journey · partner up · reach out · dive in · deep-dive · loop in · circle back · low-hanging fruit · move the needle · just · simply · easy

CTA canon (locked one-to-one)

Each verb does one job, in both languages. New copy uses these — nothing else.

  • “Email Don” — the open inbox, mailto + Window form. ES: Escríbele a Don.
  • “Run my free audit” — primary tool entry. ES: Audita mi sitio gratis.
  • “See pricing” — the studio’s posted numbers. ES: Ver precios.
  • “Book a 20-min call” — calendar onramp, not a sales pitch. ES: Reservar una llamada de 20 min.
  • “Try it free” — tool entry from a marketing page. ES: Pruébalo gratis.
  • “Save this” — Workshop save. ES: Guardar esto.

POV by page type

  • Marketing pages (home, /services/, /work/, /studio/compare/) — first-person Don.
  • Library articlesThe Muntin Desk byline. First-person “I” appears only when naming personal operator practice, never as narrator of an event. Full rule in docs/voice-canon-library.md.
  • Glossary terms — third-person reference, no “I”; the term is the subject.
  • Tool pages — second-person operator (“your menu, your numbers”), result blocks address you.
  • Trust pages (/never/, /ai/, /security/, /methods/, /accessibility.html) — first-person Don.
  • Legal pages (/terms.html, /privacy.html) — third-person studio, plain language, no legalese except where required.

Sister surfaces

  • Never — five things this studio will not do
  • AI policy — how AI is used in this studio
  • Receipts — the public counts and KPIs
  • Changelog — what shipped, when
  • Security — ten verifiable claims about how data is handled
  • The system — how the site itself is built
  • Research notes — per-source summaries cited from articles