## Review note This issue replaces `docs/gtm-strategy.md`, which has been removed from the repository so the strategy can be reviewed and edited here. The v2 document below was written before several product changes. It needs a review pass, not blind execution. ## Changes since v2 that the strategy must account for - The simulator, robot builder, scenes and build instructions were removed in commit `98245bd`. The product is physical-board only. - The flashing system is being removed entirely (decision recorded in #113). Any “simulate then flash” or “flash from the browser” positioning is historical. - Hardware is at spec/design stage, not prototype or production. Hardware buying is waitlist-only; there is no checkout or deposit. - The main shell.build repository stays private. The `shellbuild/hardware` repository is private and has no licence yet. - The remote MCP server exists and is aimed at agents and power users, not a public third-party API. - A project currently has one program; named program files with one active program are planned (#104). - Collaboration, versions, notes with image assets, PWA/desktop shell and the current editor already exist. - Marketing pages must not claim a simulator, a purchase flow, or shipped classroom features that do not exist. ## Review checklist - [ ] Re-check the “simulate-then-flash” thesis and replace it with the current physical-board positioning. - [ ] Re-check the runtime-unity claim: it must describe the current QuickJS runtime without referring to a browser simulator. - [ ] Re-check the “first 90 days” and any item that assumes flashing remains. - [ ] Re-check hardware assumptions: spec/design only, waitlist only, no self-manufacturing in year 1. - [ ] Re-check public sharing/student projects against the current private-by-default product. - [ ] Re-check pricing and purchasing assumptions. - [ ] Re-check the competitor analysis now that simulation is removed. - [ ] Decide what stays in this issue versus moving to #91 (brand/landing/SEO execution). - [ ] Record the reviewed version here; do not restore a separate strategy file unless the owner asks. --- # shell.build — Go-To-Market Strategy (v2, post-review) > **Update (Oct 2026):** the simulator has been removed from the product. The > simulate-then-flash positioning below is historical; the platform now runs > programs on physical boards only. > **Status:** v2, 12 Oct 2026. v1 was put through three independent reviews (a startup red-team, a K-12 procurement/teacher review, and a positioning/growth review). This version fixes the critical findings. Numbers are labelled **verified**, **estimated**, or **assumption**. Full source notes live in v1's appendix and the research streams; this doc keeps only decision-relevant detail. **Product:** shell.build (currently shipped under the `shell.build` domain) — a browser-native robotics + electronics lab. Users wire a circuit, write real JavaScript/TypeScript, simulate it, and flash the **same program** to a physical ESP32-C6 over USB (Web Serial, no toolchain). Offline-first, collaborative; classroom features on the roadmap. **Founder context:** solo indie developer. Everything below is sized for **one person, limited capital, no sales team**. --- ## 0. What the review changed (read this first) | v1 claim | Verdict from review | v2 position | | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | "Nobody owns simulate-then-flash; it's our moat." | **False.** micro:bit/MakeCode has simulated and flashed the _same_ program for years, free. Cirkit Designer already ships sim → "upload firmware to real hardware." Wokwi flashing is one release away. | Demote sim→flash to the **demo**. Re-anchor on **runtime unity** (one JS/TS file, one shared runtime, sim _and_ silicon, no toolchain) + the **classroom/pedagogy layer**. | | Two P0 beachheads: teens + adult JS devs. | Split focus; adult devs are a **channel**, not a customer. | **One beachhead: CTE / robotics-club teens (13–18) via their teacher.** Makers = acquisition channel + project-library supply. | | "Graduation" narrative vs competitors. | Condescending, derivative, and promises an unshipped classroom. | Identity/outcome narrative. No competitor-referential public copy. | | Hardware kit is early revenue. | Riskies move for one person; the plan argues against it internally. | **No self-manufacturing in year 1.** Partner-fulfilled / white-label packs only, after a paid classroom cohort. | | Six-tier pricing ladder. | Pre-PMF over-complexity; internally arbitrageable. | **Four live rungs.** Kill Pro year 1; don't publish district pricing. | | Public shareable student projects = #1 moat. | Collides with minor-safety/compliance. | **Default private**; anonymous handles; moderation, reporting, rate limits before public pages. | | "Insurance is the #1 blocker." | Incomplete: entity/PO/W-9 blocker is **earlier**; accessibility is a **live legal gate**. | Add entity/PO prerequisite; add WCAG-blocking gate; add cyber insurance. | | Teacher-first sales. | Right for _adoption_, wrong for _buying_ — teachers rarely cut a software PO. | Separate **champion (teacher)** from **buyer (CTE director / dept chair)**, with district privacy review running in parallel from day one. | | Two channel engines. | 3+ FTE of work; will not be executed. | **One engine for months 0–6.** Second engine demand-gated. | | SEO: programmatic glossary + comparison hub + calculators + i18n. | Over-scoped; thin pages are being eaten by answer engines. | **5–8 hand-written canonical pages** + the **user project gallery** as the programmatic engine. | **The single most important correction:** the workflow is _not_ unique, but the **combination of (a) one TypeScript file that runs unchanged on a shared browser/device runtime with no compile step, and (b) an education-grade pedagogy + classroom layer that the developer-simulator rivals do not have** is defensible. Lead with that, not with "simulate-then-flash." --- ## 1. The honest thesis **What is genuinely differentiated (defend these):** 1. **Runtime unity.** `sb-runtime` runs the same JS/TS source in the WASM browser simulator and on the ESP32-C6 firmware (QuickJS on-device), with shared tests proving the starter program works on both. This is a language/toolchain unification, not a flash button — it is the one thing a competitor cannot copy in one release. 2. **Education-grade pedagogy UX.** Every rival is a _developer_ tool (Wokwi, Velxio, Cirkit) or a _toy_ (Sphero, VEX). Progressive disclosure from first blink to typed TypeScript + collaboration is the under-served gap. 3. **Classroom/collaboration layer.** Offline-first, collaborative editing, sharing/roles already exist in the product; a no-account classroom primitive + assignments is the layer Wokwi/Cirkit don't have for 13–18. **What is NOT a moat (use as demo/proof, never as the defence):** - Browser simulation (crowded: Wokwi, Velxio, Cirkit, Crumb). - Browser flashing over Web Serial (**commodity**: ESP Web Tools, ESP Launchpad, FlashESP, ESPConnect, `esptool-js`). - "Simulate then flash the same file" as a _workflow_ (micro:bit already does it in K-12; Cirkit already does it for developers). **Contingency:** assume Wokwi (or Espressif) ships Web Serial flashing within 12 months. If that happens, the pre-committed reposition is: runtime unity + curriculum + teacher network + classroom collaboration — never "we can also flash." --- ## 2. Positioning & unique market position ### 2.1 Positioning statement > **For CTE/robotics teachers and their 13–18 students**, shell.build is the **no-toolchain hardware lab** where **one TypeScript file runs unchanged in the browser and on a real ESP32-C6** — simulated, shared, and flashed from a Chromebook — **wrapped in a classroom layer and curriculum that developer-simulator tools don't have**. Unlike Wokwi (simulate only, developer-first) or micro:bit (fixed board, blocks-first), shell.build teaches **breadboard electronics and real typed code** on real hardware. ### 2.2 Category Pick **one** noun. Recommended: **"one-file physical computing"** (or "the no-toolchain hardware lab for the classroom"). Do not chain two category labels; the audience must be able to repeat it in one breath. ### 2.3 Narrative (identity/outcome, not "graduation") - "Real code, real electronics, on real hardware — from a browser tab, on the Chromebook you already have." - "Write it once. Simulate it. Flash it. Same file, no toolchain." - "The hardware lab that fits in a tab." ### 2.4 Proof points (the demo + the substance) 1. **The 60–90s demo:** wire → Run (sim) → Flash over USB → real LED blinks. _(Verified: the product's default project is exactly this LED-blink flow, so the hero asset matches the shipped product. Keep it that way.)_ 2. **Guest, no-signup editor** with that pre-wired project. 3. **Offline-first + Chromebook-native**, no install, no admin-rights journey (with an honest supported-devices page). 4. **Typed JS/TS**, not blocks — answers the CTE "blocks aren't real programming" objection. 5. **Same runtime both targets** — the technical proof behind "same file." 6. **"Sim vs real: known differences" page** — pre-empt the inevitable "the motor jittered on the real board" moment and neutralise a Wokwi-accuracy attack. Honesty is a differentiator. ### 2.5 Counter-positioning (private map, not public copy) Wokwi → workflow/hardware/K-12 fit, never "better simulator." Tinkercad → continuation into real hardware. Arduino → better front-end to the same class of silicon; offer ESP-IDF-compatible export. micro:bit → **never** claim it doesn't simulate; position on typed code, arbitrary circuits, ESP32 as the "next board." VEX/Sphero → electronics vs driving. LEGO → durable software where code outlives the kit. Cirkit/Velxio → "they built a developer simulator; we're building the classroom." --- ## 3. Beachhead & buyers ### 3.1 One beachhead **CTE / robotics-club teachers and their 13–18 students on Chromebooks.** Everything in year one points here. | Role | Who | What they do | Not their job | | --------------- | ---------------------------------------------- | --------------------------------------------------------------------------- | ------------------------- | | **User** | Student (13–18) | Uses the tool | **Does not buy.** | | **Champion** | CS/CTE teacher, robotics coach | Pilots free, gives feedback, becomes a reference, writes the pilot proposal | Rarely cuts a software PO | | **Buyer** | CTE director / dept chair / pathway lead | Controls program-of-study budget; approves the first real PO | — | | **Gatekeepers** | District IT/CIO + privacy officer + purchasing | Veto on devices, data, process | — | **Makers (adult JS/TS devs, hobbyists) are a channel, not a segment:** they supply the project library, credibility and content, and occasionally a Pro-style donation — but the business is not built on them. ### 3.2 Explicit year-one non-targets K-8/PK-3 (needs a Blockly layer), higher-ed/industrial sim, iPad/Safari-only classrooms (simulate-only fallback), district direct sales, IoT/fleet buyers. **Brand surface:** run the school-facing identity separately from the hobbyist surface if reviewer caution holds (consider `shell-build`/edu vs `shell.build`) so the school brand doesn't read "hobbyist tool." --- ## 4. Product readiness & gating ### 4.1 Hard gates before public beta - [ ] Guest, no-signup editor with a runnable LED-blink project. - [ ] **Flash reliability across Chrome/Edge on Windows/macOS/ChromeOS**; `flash_started/succeeded/failed` event taxonomy + diagnostics on failure. _(Today only 5 project-lifecycle events exist — fix before launch.)_ - [ ] **Supported-devices + Web Serial test page** (helps IT, not just teachers). - [ ] 3–5 one-click example projects; shareable links; fork/remix. - [ ] **"Sim vs real: known differences"** + per-component compatibility matrix. - [ ] **Child-safety baseline:** projects **default private**, anonymous handles, report/report flow, moderation queue, rate limits, no PII in public corpora. - [ ] **WCAG 2.2 AA on the guest editor + `/teach` + lesson pages** (keyboard-operable wiring, non-colour state cues, captions, focus management) — a _documented-gap ACR is a district veto_. - [ ] Landing-page honesty fix: mark unbuilt Classroom/School tiers "coming soon / join the beta." ### 4.2 Hard gates before classroom beta - [ ] No-account classroom join (class code / join-by-link) **as the default free experience**. - [ ] Lightweight teacher view (student projects), not a full LMS. - [ ] Google + Microsoft SSO; Google Classroom roster import (note: sensitive-scope OAuth verification takes weeks). - [ ] Signed DPA + state exhibits (CA AB 1584, IL SOPPA, NY Ed Law 2-d at minimum); retention/deletion policy + named data-protection contact; COPPA posture updated for the **Apr 2026 amended rule**. - [ ] **One complete 6–9 week pathway** co-authored with 3 teachers — including answer keys, rubrics, a **no-hardware substitute track**, and **IEP/504/ELL scaffolds** — aligned to CSTA 2026 (incl. Physical Computing), ISTE, NGSS ETS1, and the teachers' **state CTE standards**. - [ ] Cyber + general liability insurance and a vendor packet (see §8). ### 4.3 Explicitly deferred (demand-gated) Clever / LTI 1.3 / OneRoster (build SSO → ClassLink → OneRoster → LTI before _school #2_, not school #50), SOC 2, org/class/assignment domain model, self-manufactured hardware, billing beyond the first paid SKU. --- ## 5. The offer (year-one scope) **Year one offers exactly two things a user can do, and exactly one thing a buyer can buy.** 1. **Free tool (forever):** simulator, guest editor, projects (default private; opt-in public with moderation), 1 device, 1-flash-at-a-time, community support. This is the acquisition engine. 2. **Free teacher pilot:** 3–5 design-partner classrooms, free for the school year in exchange for feedback + a testimonial + outcome data. **Grandfather them in writing.** 3. **One paid SKU, demand-gated:** a **classroom pack** (class-sized board set + storage + the 6–9 week curriculum + a classroom licence), sold **via PO / DonorsChoose / reseller**, not self-manufactured (see §7.3). ### 5.1 Pricing ladder (four live rungs) | Tier | Price | Notes | | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- | | **Free** | $0 forever | Simulator + guest editor + private projects | | **Classroom** | **~$249/yr per teacher** (covers _all_ their sections/students) | Kills the $199/35-seat arbitrage; easy PO. To validate. Beta classrooms grandfathered free for 12 months | | **Classroom Pack** | **~$1,200–1,500 via PO** (class-sized: ~25 boards + 5 spares + storage + curriculum) | The first paid SKU; partner-fulfilled. CPAs _supplies_ budget, not SaaS | | **Bundle** | Classroom + Pack | Best conversion | | _Later (do not advertise):_ School (by enrollment band, monotonically lower per-seat), District (quote) | | Gate behind references + SSO/OneRoster + DPA + ACR | **Kill the Pro tier in year 1** (or make it a pure "supporter" donation with no gating) — it competes with free Wokwi and cannibalises the funnel. ### 5.2 Why this prices correctly - Free incumbents (Tinkercad, MakeCode, micro:bit classroom, Wokwi Community) anchor the simulator at $0 — **so we never sell "a better simulator."** We sell **saved teacher time** (curriculum, assessment, classroom workflow) and **hardware**. - The pack is priced ~25–35% of hardware-first classroom kits (Ozobot Evo 12-pack $2,050; Sphero indi 8-pack $1,500) with a class-sized unit — a strong budget story. --- ## 6. Revenue model, viability target & kill criteria ### 6.1 Viability target (the thing v1 was missing) - **Founder must clear ≥ $3k/mo gross profit by month 12, and ≥ $8k/mo by month 18.** If not met, execute the pivot: (a) drop hardware entirely and sell **curriculum + classroom software** only; or (b) raise/park the project. **Kill date: month 18.** - This is stated up front because v1's own model (~$73k software ARR at month 24) does not by itself fund a founder; **hardware/curriculum gross profit must lead early, software must compound.** ### 6.2 Reality check (assumptions, labelled) Free signups 1k→4k/mo; 4% free→paid; ~90 classrooms and ~15 school sites by month 24; hardware packs 10→40/mo. Under these assumptions software ARR ≈ $22k (mo 12) → ~$73k (mo 24); cumulative hardware/curriculum GP ≈ $61k → ~$265k. **Treat every input as a placeholder with a validate-by date; set real targets from the first cohort.** ### 6.3 Bottom-up market model (replaces v1's unfalsifiable TAM) - **US secondary CS/CTE teachers** × realistic ACV (Classroom + occasional pack) = the serviceable market we can actually reach. - **Classrooms we can personally reach in 12 months** (teacher network + conferences + content) × pilot→paid conversion = year-1 target. - Cite **one dated primary source per number**; drop the "$1.15–6.5B" range from decision-making (keep it as context only). ### 6.4 First 10 paying customers (who, channel, price, date, what must be true) 1–3. **Pilot teachers → paid packs** (channel: direct; price: ~$1,200 PO; by month 6; _must be true:_ pilots produce a measurable outcome + a quote). 4–6. **DonorsChoose-funded kits** (channel: DonorsChoose via a US vendor listing; ~$800–1,000; months 5–9; _must be true:_ US vendor/entity + a sub-$1k project). 7–8. **Robotics clubs** (Hack Club / FIRST teams; channel: community; ~$1,200; months 6–10; _must be true:_ club budget or sponsor). 9–10. **CTE department PoCs** (channel: reseller on an existing co-op/state contract + Amazon Business PO; months 9–12; _must be true:_ champion + dept budget + insurance). --- ## 7. The growth loop & channels ### 7.1 One loop (this is the engine) **Embeddable live simulation + public remix gallery.** - Every public project gets an indexable URL with **fork/remix**. - Every project can be **embedded** (`