# shell.build GTM strategy v3 (draft)

> **Status:** draft for owner review, 3 Nov 2026. This replaces `docs/gtm-strategy.md`, which has been removed from the repository. v2 is preserved collapsed at the bottom for comparison.
>
> **Evidence labels:** **verified** means checked in the repository or this session; **assumption** means a hypothesis to test; **unknown** means no decision yet.

## 0. What changed since v2

These are the product changes the strategy must now reflect:

- **Simulation is permanently removed** (commit `98245bd`). The simulator, robot builder, scenes and build instructions are gone. The product runs programs on physical boards only.
- **Firmware flashing is being removed.** Boards are pre-flashed and update over the air through the firmware protocol. In-app program upload stays.
- **Hardware is spec/design only.** `cad/DESIGN.md` is a draft. There is no prototype build, manufacture or inventory plan yet.
- **Hardware buying is waitlist-only.** There is no checkout, deposit or preorder.
- **The main repository stays private.** The `shellbuild/hardware` repository is private and has no licence; making it public is a separate decision.
- **The product surface is broader than v2 assumed:** collaboration, versions, notes with image attachments, PWA/desktop shell and a remote MCP server already exist.
- **Projects currently have one program.** Named program files with one active program are planned; version history is project-wide.
- **MCP and the API are for agents and power users**, not a public third-party platform.
- **Public share links are planned as unauthenticated read-only live views.** This is a change from the private-by-default assumption in v2 and needs safety controls.

## 1. Product today (verified)

A browser-native robotics and electronics lab:

- write TypeScript in a Monaco editor;
- upload and run the program on a physical ESP32-C6 board over the shell.build protocol;
- collaborate in real time, save versions, and keep notes with images;
- install as a PWA or use the desktop shell;
- connect an agent over MCP for read/write project access.

There is no simulator, no in-app firmware flashing and no purchase flow.

## 2. Thesis

**Lead with runtime unity on real hardware, not simulation.**

The defensible combination is:

1. **One TypeScript program and one runtime model** that runs on the board, with no local toolchain and no compile step for the user.
2. **A classroom-grade collaboration and teaching layer** that developer tools do not have.
3. **A no-toolchain browser workflow** that works on the Chromebooks schools already own.

The old “simulate then flash the same file” story is retired with the simulator. The new proof is “write it in the browser, run it on the board, share what you built.”

Status: **assumption** that this is legible and valuable to the target buyer. It needs teacher validation.

## 3. Audience

**Leading hypothesis (carried from v2, needs confirmation):** CTE and robotics-club students aged roughly 13–18, reached through their teacher.

- The **champion** is the teacher.
- The **buyer** is the CTE director, department chair or school administrator.
- Adult makers and independent developers are an acquisition channel and a source of project examples, not the primary customer.

**Unknown:** whether the target should stay this narrow after the simulator removal. The owner must confirm or replace this before the landing page is rewritten.

## 4. Offer and buying

**Verified:** hardware is waitlist-only. There is no payment, deposit or checkout.

The near-term offer is therefore:

- a free browser editor and project library;
- a hardware waitlist that measures demand;
- design-partner conversations with teachers;
- no paid hardware or software commitment until the waitlist and design partners justify it.

**Assumption:** the first revenue should not depend on self-manufactured hardware. v2 already argued against inventory in year 1; that still holds.

**Unknown:** software pricing, school vs individual tiers, and whether hardware is sold by a partner or by shell.build.

## 5. Acquisition

Keep one engine for the first six months:

1. **Teacher design partners** — a small number of classrooms using the product and giving feedback.
2. **Hardware waitlist** — demand validation, not a revenue stream.
3. **Examples and share links** — curated projects plus unauthenticated read-only links give teachers something concrete to send to colleagues.
4. **A small set of canonical SEO pages** — hand-written, truthful pages for the actual product. Do not scale thin comparison pages.
5. **The build gallery** — only after moderation, reporting and minor-safety controls exist.

No conferences, paid ads, affiliate programme or district sales in the first phase.

## 6. Proof and demo

The 60–90 second demo should be:

1. open a curated example in the browser;
2. connect a pre-flashed board;
3. upload and run the program;
4. change the code and run it again;
5. open a read-only share link.

Do **not** show a simulator, a firmware-flash button, or a checkout.

## 7. Pricing

**Unknown.** Do not publish a pricing ladder yet.

The only pricing claims allowed on the site are the waitlist terms that actually exist. If the page says “reserve” or “charged when your kit ships”, that must be removed unless the owner opens a real preorder.

## 8. Risks

- **Onboarding without simulation.** A browser-only demo used to be the top of the funnel. Without it, the waitlist and examples have to carry more weight.
- **Firmware update path.** Removing flashing shifts responsibility to pre-flashed boards and OTA. If OTA is not ready, a board with old firmware is a dead end.
- **Hardware dependency.** Hardware is spec-only, so the software must stand on its own until boards exist.
- **Public share links and minors.** Unauthenticated live links need revocation, rate limits, noindex by default and a reporting path.
- **Private repository.** The community cannot inspect or contribute to the main codebase; the public hardware repo is the only open surface.
- **Trust.** Several old claims (simulation, flashing, purchase) are now false. Every page must be audited.

## 9. First 90 days (draft)

1. Confirm the audience and recruit 2–3 teacher design partners.
2. Review the hardware draft; keep it spec-only until the open electrical decisions are settled.
3. Make the pre-flashed-board onboarding path work end to end and ship OTA firmware updates.
4. Rewrite the landing page to the physical-board story; remove simulator, flashing and purchase claims.
5. Ship read-only public share links with safety controls, then use curated examples as the first public projects.
6. Instrument the funnel: waitlist signup, project created, program uploaded to a board, share link viewed.

## 10. What we will not do (year 1)

- No simulator or “simulate then flash” positioning.
- No in-app firmware flashing.
- No checkout, deposit or preorder until the owner decides.
- No self-manufactured hardware or inventory.
- No public third-party API.
- No district sales, conferences, paid ads or affiliate programme.
- No public student projects without moderation, reporting and noindex defaults.

## 11. Open questions for the owner

- Is the CTE-teen-via-teacher audience still correct?
- Is the first revenue software, hardware, or a partner-fulfilled kit?
- What is the pricing model, if any?
- Which hardware partner/fabricator, if any?
- Does the main repo ever become public?
- What is the minimum OTA path needed before hardware can be sold?

---

<details>
<summary>Original v2 strategy (historical)</summary>