AI-Native Team Diagnostic

An interactive, self-scoring assessment that helps teams find out how AI-native their operating model actually is — not just whether they're using AI tools, but whether the way the team works has been redesigned around them.

Three versions live in this repo, each adding one layer of capability.

🌐 Live site: shayeeboy.github.io/ai-native-diagnostic — landing page linking all three versions.

---

Executive Summary

Problem. Teams adopting AI tools rarely have a shared, structured way to assess how "AI-native" their operating model actually is. Readiness conversations tend to happen informally and inconsistently — one person's "we're pretty advanced" is another's "we've barely started" — which makes it hard to prioritize where to invest next.

User. A team lead or functional manager who wants a fast, structured readiness read for their own team, and — in the v3 shared version — a manager or leadership group who wants to compare readiness across teams in one place rather than reading fragmented spreadsheet answers.

Objective. Give teams a structured, repeatable way to answer "how AI-native are we, really" — replacing an informal, inconsistent conversation with a scored, comparable diagnostic that also outputs a concrete next step (the 90-day plan), not just a score.

Success metric. Primary: completion rate — % of started assessments that reach the generated diagnosis. Secondary: for v3, number of teams with at least one completed, shared result — as a proxy for whether the tool is actually being used for comparison, not just solo reflection. (No usage data has been collected yet — this is the metric I'd instrument first if this moved from portfolio piece to something a real team used.)

Key trade-off decisions.

• Persistence added incrementally (v1 → v2 → v3), not upfront. Each version only added the next layer of infrastructure once the previous version's limitation was clear — avoided over-building a backend before confirming anyone needed multi-device or team-shared results.
• Static front end (GitHub Pages) + thin Render API + Neon, over a single full-stack framework. Kept the front end as plain static pages and the backend as a minimal Express API — trading some flexibility for near-zero hosting cost and fast iteration, appropriate for a v1 still validating whether the shared-comparison use case matters.
• Browser print-to-PDF instead of a generated report file. Simpler and zero-maintenance, at the cost of a less polished output than a purpose-built PDF export.

How it works

The three versions below show how it works, each adding one layer — from a zero-setup static page (v1), to browser-local auto-save (v2), to a shared Express + Neon backend for team-wide comparison (v3).

---

v1 — v1/index.html

The original build. Fully interactive, scores live, generates a diagnosis report at the bottom. Nothing is saved — close the tab and it's gone.

Use this when: someone wants to try the tool once with zero setup, or you're sharing it widely and don't want to explain any save/restore behavior.

🔗 shayeeboy.github.io/ai-native-diagnostic/v1/

v2 — v2/index.html

Same diagnostic, plus auto-save. Answers save to the browser's local storage as you go, and a banner offers to restore your last session if you reopen it. A name field lets you label your saved session. Saving is local to one browser on one device — no team-wide visibility.

Use this when: someone might fill it out over multiple sittings on the same device.

🔗 shayeeboy.github.io/ai-native-diagnostic/v2/

v3 — v3/ + v3-backend/

Real shared persistence. A small Express + Postgres API backs the front end so everyone on the team can see everyone's completed diagnostics — not just their own.

Use this when: you want the team comparison view — not just "did I finish mine," but "where does the whole team land."

🔗 shayeeboy.github.io/ai-native-diagnostic/v3/

Architecture:

• Front end: v3/index.html, served via GitHub Pages alongside v1 and v2
• Backend: Node.js/Express API hosted on Render (free tier)
• Database: Postgres via Neon (free tier, no inactivity expiry)

Access control (added 2026-11-01). The team view was originally readable by anyone who had the API URL, including every respondent's name and free-text answers, and any session could be edited or deleted by its id. Now:

• the team view needs a team access code (TEAM_ACCESS_CODE on Render) and shows only name, score, bottleneck and date — no free text. If the code isn't set, the team view stays closed;
• each new session gets a private edit key that stays in the person's browser (only its hash is stored), and reading, updating or deleting a session needs that key or the team code;
• the aggregate /api/snapshot used by the Studio is unchanged (no names or free text).

Covered by npm test in v3-backend/ (8 access-control tests). Details in v3-backend/README.md.

---

以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗