Leer este artículo en español →

Most “free margin audit” tools have a price tag. It's just paid in data. The pattern is well-worn: you type your real ticket, your real food cost, your real labor — and the tool returns a number. It also tends to return sales reps in your inbox by morning, each with a proposal built on numbers that were never supposed to leave your office. The tool was the funnel. Your numbers were the qualifier.

The pattern hides because nobody asks the obvious question: where do my inputs go the moment I type them? In a working browser, you can answer that question in under a minute. This article is the framework — five tests, four data tiers, one worked example — and at the end, a checklist you can run on any tool you encounter.

The tools that pass these tests will tell you so, plainly. The tools that fail are about to explain why the tests don't apply to them. That's the tell.

1. The five tests — run before you type

Open DevTools ↗ on whatever tool you're evaluating (Cmd+Opt+I on Mac, Ctrl+Shift+I on Windows). Five questions:

  1. Does typing a number trigger a network request? Open the Network tab. Type. If the request list grows on every keystroke, the tool is silently sending your inputs to a server. Walk away.
  2. Is the privacy claim at the point of input? A trustworthy tool tells you what it does with your data where you're typing — not in a footer link three clicks deep.
  3. Is there an account / newsletter / cookie gate? “Enter your email to see your results” means your numbers are the price of admission. The tool is not free.
  4. Are there third-party analytics, session replay, or marketing scripts? Filter the Network tab by JS. If you see Google Analytics, Meta Pixel, HubSpot, FullStory, Hotjar — your inputs are being recorded by surveillance vendors who weren't even part of the deal you thought you were making.
  5. Is the source code readable? Right-click → View Source. A small, readable, unminified script is a tool you can audit. A 4-megabyte minified bundle from a SaaS framework is a tool you can't.

Pass all five and the tool is at least honest about its data flow. Fail any of them and the tool either doesn't know or doesn't want you to know — both are reasons to leave.

  1. 1

    Network on keystroke

    Open Network tab, type a number. If the request list grows per keystroke, the tool is silently shipping inputs to a server. Fail = walk away.

  2. 2

    Privacy at the point of input

    A trustworthy tool tells you what it does with your data where you are typing — not in a footer link three clicks deep. Fail = walk away.

  3. 3

    Account / email / cookie gate

    “Enter your email to see your results” means your numbers are the price of admission. The tool is not free. Fail = walk away.

  4. 4

    Third-party scripts

    Filter Network by JS. GA, Meta Pixel, HubSpot, FullStory, Hotjar — surveillance vendors who were never part of the deal. Fail = walk away.

  5. 5

    Readable source

    Right-click → View Source. Small, unminified, every function named = auditable. 4MB minified SaaS bundle = you cannot. Fail = walk away.

The five tests in run-order. Any one failure ends the audit; pass all five and the tool is at least honest about its data flow.

2. The four-tier model — what to share, where

Most small-business owners carry all their data in the same mental bucket — which means the supplier list and the tax ID get the same protection (often the same low level of it). Four tiers, each with a different audience and a different level of caution:

  • Tier 1 — Public. Menu, hours, photos, address, phone, schema.org markup. Optimize aggressively; this is how customers find you.
  • Tier 2 — Competitive-sensitive. Cost of goods, supplier list, your actual commission tier (not the public rate), labor schedule template. Share with bookkeeper / consultant / broker — under NDA. Not with platforms, competitors, or “free audit” tools that keep your input.
  • Tier 3 — Operational-confidential. Monthly P&L, actual food cost %, customer pipeline, employee schedules. Inside the business only. POS vendor, payroll, accountant — and only under written contract.
  • Tier 4 — Regulated. SSN, EIN, customer card data, bank details, food-safety logs, I-9s. Encrypted storage, access logging, contracts with cybersecurity terms. Never email. Never in a shared spreadsheet.

The principle: data never flows up a tier. A Tier 3 vendor doesn't get Tier 4 access just because they asked. A Tier 1 audience (a platform, a listing site) doesn't get Tier 2. The easiest way to reduce your attack surface is to stop volunteering data that wasn't actually required.

Tier 1: Public data flows fully open T1

PublicMenu, hours, photos, address. Optimize aggressively.

Tier 2: Competitive-sensitive data flows under NDA only T2

Competitive-sensitiveSuppliers, costs, real commission tier. NDA only.

Tier 3: Operational-confidential data stays inside the business under written contract T3

Operational-confidentialP&L, food cost, pipeline, schedules. Contract only.

Tier 4: Regulated data is encrypted only, never email, never shared spreadsheets T4

RegulatedSSN, EIN, card data, I-9s. Encrypted only. Never email.

Four tiers, four allowable audiences. The ring shrinks as the data tightens. The single rule: data never flows up a tier.

3. What “safe” looks like — the worked example

Here's the standard every tool on this site is held to. Nine claims about how every Muntin tool handles your inputs, each one verifiable in your own browser. Tap any claim to see the DevTools step that confirms it.

The full version with each claim's specific DevTools verification step lives at /security/. Four of them (1, 2, 4, 5) are build invariants — the cohesion-check pass that runs on every deploy fails CI if a future tool ships a forbidden pattern. So “verifiable” isn't marketing copy; it's a contract enforced by the build, with a public hash of the production bundle published at /security/integrity.txt.

  1. 1

    Network on keystroke — pass

    No fetch(), no XMLHttpRequest, no form POST fires when you type a number. Every calc runs in the browser. Build invariant.

  2. 2

    Privacy at the point of input — pass

    The privacy line sits next to the input. No server to store inputs on, only GET /tools/<slug>/ for the page itself. Build invariant.

  3. 3

    Account / email / cookie gate — pass

    No sign-in. No email capture. No cookie wall. No localStorage or sessionStorage holding your inputs — close the tab, the form is empty.

  4. 4

    Third-party scripts — pass

    Only Plausible analytics loads, and it sees only bucketed event names — a $25 ticket becomes 25-39. Build invariant.

  5. 5

    Readable source — pass

    No build step, no minification, every math function named. View Source returns a script you can read in five minutes. Build invariant.

The five tests run against a Muntin tool. Four of the five passes are enforced as build invariants — the cohesion check fails CI if a future tool ships a forbidden pattern.

"Verifiable" should be a build flag, not a marketing claim. If the only proof is the brochure, treat it as the brochure.

4. Run the audit

The 5-test framework is also an interactive checklist at /learn/checklists/audit-any-tool/ — walk through it with DevTools open on any tool you're evaluating. Save the result to your Workshop as a baseline; re-run it whenever a vendor pushes a “new feature.”

And if you find a tool that fails the audit but you can't tell whether it's malicious or just sloppy, write through The Window and tell me about it. I read every one. The pattern of free tools that quietly turn operators into the product is worth naming — out loud, with the tool's name attached.

Tell us

Be the first field note on this piece.

Tried this in your own restaurant? 100–400 words, your name on it. Don reads every one. Your note shows up here once approved.

Sources & further reading

OWASP — client-side data exposure

OWASP — OWASP's ongoing guidance on client-side data exposure underpins Test 4 (third-party scripts) and the principle that any input typed into a page reachable by GA, Pixel, or session-replay vendors should be treated as published. The categories of script flagged in Test 4 (analytics, session replay, marketing) map to OWASP's "untrusted client-side data" risk class.

NIST data classification frameworks

NIST data classification frameworks — The four-tier data model in this post is operator-friendly framing of NIST SP 800-60 Volume I — the federal data-classification framework that distinguishes Public / Sensitive / Confidential / Regulated. The vocabulary differs; the principle ("data never flows up a tier without a contract") is the same one NIST applies to federal information systems.

RFC 3986 — URL fragment behavior

RFC 3986 — The "shareable scenario links use the URL fragment" claim relies on RFC 3986 §3.5: browsers do not transmit the fragment portion of a URL to the server in HTTP requests. This is what makes fragment-encoded scenario links a valid privacy-preserving share mechanism.