Is notion.so vibe coded?

Reading this score

notion.so landed on 13/100, which puts it in the hand-written band. That number is not a percentage and not a probability — it is strength of evidence: 28 points of tells, damped by craft, less 32 points of deliberate decisions, mapped through one logistic curve.

What pushed it up

• Heavy for what it renders +10 — 54 script files and 174 KB of HTML to render 352 words. A full framework, an icon library and an animation library for a page a hundred kilobytes could serve.
• Dependency sprawl +8 — 2 third-party asset hosts and 54 script files. Each sub-problem got whatever library was most popular in the training data, and nothing was ever consolidated.
• Fixed pixel widths that will overflow a phone +8 — Hard pixel widths wider than a phone. Layouts break at sizes nobody prompted for, because desktop was the only viewport that got looked at.
• A bento grid because bento grids exist +5 — Asymmetric tiles used as a style rather than because some tiles matter more. If shuffling them changes nothing, the grid is decoration.

What pulled it down

• Deliberate social preview −9 — Open Graph title and image were both authored.
• Hand-written ARIA −7 — 107 explicit accessibility attributes.
• Semantic landmarks −6 — 6 landmark elements instead of a pile of divs.
• CSS custom property system −6 — 169 CSS custom properties — a real token layer.
• Canonical URL −4 — Canonical link is set.

Craft we looked for and did not find

These are the actionable half of the report. None of them are hard, and every one of them would have moved the number.

• Structured data
• Skip-to-content link
• prefers-reduced-motion honoured
• Self-hosted typography
• Hand-authored stylesheet
• No utility-class soup

What this scan cannot see

One request, no JavaScript executed. So everything below is invisible to us, and a page can be excellent or awful at all of it without moving the score:

• Domain registration age — needs WHOIS.
• Whether the nav's /about and /pricing actually resolve — needs a crawl, not one fetch.
• package.json dependency count, orphaned code, clashing abstractions, test coverage — needs the repo.
• Backend security shortcuts: string-built SQL, verify=False, missing auth on endpoints — needs the source.
• Whether row-level security or Firebase rules are actually switched on — needs the project.
• Console errors, hydration warnings and runtime 404s — needs a browser executing the page.
• Real Lighthouse numbers and horizontal scroll at 375px — needs a rendered viewport.
• Whether a JS-handled form posts anywhere — needs a submitted request.