Documentation

Free structural checks, Basic $5/mo, Pro $19/mo. Sibling product to Preflight.

Overview

Design Check scans HTML/CSS/copy/interaction for the patterns that make AI-generated work read as generic. "Design" here covers more than what a page looks like. Individual visual tropes matter, a gradient here, a pill button there, but composition matters more: does the layout vary width and background across sections, or is it one unvarying centered column the whole way down. Writing quality is checked the same way. So is whether the experience actually helps someone: a tool that names a problem and stops there has failed at the design of the interaction, whatever it looks like.

REST API

POST /api/check

curl -X POST https://designcheck.allthepossibles.com/api/check \
  -H "content-type: application/json" \
  -d '{"url": "https://example.com"}'

Body (exactly one of):

Response is a CheckReport: score (0-100, higher is more distinctive), verdict (generic / mixed / distinctive), and a findings array. Each finding has severity, category, title, detail (what's wrong and why), and fix (a concrete next step, not just a diagnosis).

GET /api/stats

Aggregate verdict counts across every check run through Design Check.

GET /status

Live health check. Returns {"status": "operational"}.

MCP server

{
  "mcpServers": {
    "designcheck": { "url": "https://designcheck.allthepossibles.com/mcp" }
  }
}

check_design takes the same input shape as /api/check and returns the report as JSON text content. check_copy is the same engine narrowed to a single text field, for checking marketing/outreach copy directly rather than a page. check_code narrows it further to a single code field, for a source file or diff instead of prose.

Findings & scoring

Score starts at 100 and loses points per finding by severity (critical −30, high −18, medium −10, low −4). Under 50 is generic, 50–79 is mixed, 80+ is distinctive.

When you pass a url, the typography and color checks don't only look at inline <style> blocks and inline style="" attributes: they also fetch up to 5 linked stylesheets (<link rel="stylesheet">) and fold that CSS in before running. Most real sites (Next.js, Vite, Tailwind's build output, Framer, Webflow, v0, bolt.new) ship their actual design as a linked file, not inline CSS, so this matters for whether the checks see anything real. Raw html input isn't fetched from, so this only applies to url checks.

The pill-CTA check requires the rounded-radius signal and the arrow glyph on the same <a>/<button> element, not just present anywhere on the page. A data-dense app can have an unrelated 50%-radius status dot far away from an unrelated "See all →" link; that's not a pill-shaped CTA and doesn't get flagged as one.

Rate limits

20 checks/minute per caller IP on the free tier, tracked in D1. A 429 means you've hit it. Two paid tiers raise that ceiling, on both /api/check and /mcp: Basic ($5/mo) gets 150 checks/minute, Pro ($19/mo) gets 500. Basic runs the exact same checks as free and Pro, structural and copy and code, all of it; the only thing it buys is the higher limit. The vision pass (a real screenshot, critiqued directly) calls a paid Claude API on every run, so it has two modes. Bring your own key: send your Anthropic key in an x-anthropic-key header and the pass runs on your account, on any tier including free. We don't store or log the key. Full service: a Pro subscription that has been paid for runs it on ours, up to a monthly allowance. A Pro key still in its 7-day trial uses the bring-your-own-key mode until the first payment. Send an Authorization: Bearer <key> header to use a paid key; get one at the homepage. Still hitting a limit that's genuinely in your way: say something.

Known limitations

The structural checks (typography, color, component, layout, copy, experience) are regex and string analysis over HTML/CSS/text, not a rendered screenshot, so they only partially cover real gestalt-level issues: whether a page actually looks composed once a browser renders it. The vision pass closes that gap by taking a real screenshot and having Claude critique the rendered result directly, but it needs a live url to screenshot. It can't run against raw html with no page to fetch.

Structural HTML parsing here is regex-based, not a full DOM parser. v1, expanding as real false positives and negatives get reported.

The "diagnosis with no next step" check looks for problem words (issue, error, broken, missing, etc.) with zero fix-oriented language anywhere on the page. Bare word matching can't fully disambiguate word sense: "issue"/"issues" specifically is gated on a preceding determiner ("an issue," "known issues") so the verb sense ("we'll issue you a new key") doesn't get counted as a diagnosed problem, but other words on the list don't get that same treatment yet. If a word on either list is misfiring in a specific way you're hitting, that's useful to report.

Why the source isn't here

Same reasoning as Preflight: publishing the exact detection patterns makes them easier to write around on purpose. What's public is this documentation, the methodology, and a public repo for issues.

Support

Found a false positive, a false negative, or something broken: open an issue.

Managing a Pro subscription, invoices, payment method, cancellation: /billing. There's no account login on an API-key product, so it's a form that takes your key and hands you straight to Stripe's own billing portal, nothing is stored beyond validating the key belongs to an active subscription. Checking how many checks a key has run this billing period: /usage, or GET /api/usage with the key as a Bearer token.