Editions strategy — why more than one surface exists¶
Audience: founder, operators, finance, partners who need the why, not the flag names.
Sources: packaging and cloud-run technical contracts, cloud-edition business case, access/cohort design, marketing site content, release notes.
Rule: no invented demand, pricing, or run-rate numbers. Gaps marked TODO(verify).
1. The problem multiple editions solve¶
WorkWingman has two honest product truths that pull in opposite directions:
| Truth | Implication |
|---|---|
| Default product is local-first desktop | Privacy story, BYOK AI, full feature depth, data on the user’s machine. Best for real job-search work. |
| Some audiences will not install a Windows app first | YC review, remote teammates, and timed user tests need a browser path with a short menu and hard blast-radius limits. |
A single “one binary, one cloud login, full product for everyone” surface would either:
- force multi-tenant SaaS before storage and routes are tenant-safe, or
- force reviewers through an installer + local setup that kills first-look conversion.
So the strategy is editioning by risk and audience, not by vanity SKUs.
2. What we actually maintain (and why)¶
2.1 Public desktop (NSIS installer)¶
Why it exists
- Primary product: full HelPeR behavior on the user’s PC.
- Marketing and packaging promise: one program, one install, no developer toolchain on the tester’s machine.
- Chromium for vault/login automation ships in the box so “clean laptop” demos do not fail mid-flow.
Cost / benefit
| Benefit | Cost / risk |
|---|---|
| Strong privacy and trust story (local-first) | Installer size (~hundreds of MB with runtime + browser); SmartScreen until signing reputation |
| Offline-capable first launch | Build complexity (publish API + bundle Chromium + NSIS) |
| Shareable beta without hosting multi-tenant data | Support burden of unsigned or early-signed EXE; update feed must be operated deliberately |
| electron-updater path for later self-serve updates | Feed URL configured but package still flags unpublished build — TODO(verify) live feed ops |
Strategic role: default GTM and everyday use. Cloud does not replace it in the current contracts.
2.2 Hosted server edition (invitation + Google cohorts)¶
Why it exists
- YC reviewers: bounded evaluation without desktop install.
- Team testers: parallel invitation-gated surface without pretending the whole desktop repo is multi-user-safe overnight.
- Internal / user-testing / QA cohorts: Google allowlists so real people get the right workspace and telemetry label (including excluding QA noise from user-testing analysis).
Cost / benefit
| Benefit | Cost / risk |
|---|---|
| Browser first look for investors/reviewers/teammates | Cloud Run, load balancer, Firestore, Secret Manager, invitation ops |
| Audience separation (YC vs team codes; cohort isolation) | Rate limits, CSRF, session HMAC, secret rotation, live boundary verification |
| Private workspace per redemption (avoid shared demo chaos) | Support for code distribution and revocation |
| Hard route allow-list / 503 for non-pilot APIs | Product looks “thin” next to desktop — must be explained honestly |
| AI spend brakes on pilot paths | Absolute budgets and full COGS still TODO(verify) |
| User-testing flag for surveys/insights | Telemetry governance; multi-tenant legacy store caveats when routes unlocked |
Strategic role: private pilot and learning, not yet a claim of full SaaS. Desktop remains the default product in technical and business cloud docs.
2.3 QA / dual-role (“Test Bench” language)¶
Why it exists
- QA needs a shared workspace pattern (
qacohort can disable per-member private workspaces). - Some people hold two jobs (e.g. Test Bench QA and real user testing). Exclusive cohorts plus a deliberate multi-mode email list force an explicit session choice so telemetry and workspace isolation stay honest.
What we do not claim
- A formal mock vs live Test Bench product pair is not specified in this repository. Treating “mock/live” as shippable editions would invent structure. Closest real dual axes: cohort mode choice, desktop real/sandbox data worlds, and prod vs qa deployment rungs.
Cost / benefit: better metrics hygiene and dual-role ergonomics vs config complexity and the risk that unknown audiences fall to capability “locked” until mapped.
2.4 Docs audiences (yc-reviewer / team-test) and marketing site tiers¶
Why it exists
- In-app docs: fail-closed per document so team-only material never ships to YC review sessions (and vice versa for YC-only fixtures).
- Marketing site: separate Team / Internal / Tester email tiers for brochure/docs cards — different system, different lists.
Cost / benefit: confidentiality and staged disclosure vs two parallel allowlist systems operators must not confuse. Env-ladder “live-only reader settings” hazard remains TODO(verify) for exact keys.
2.5 Public cloud site (MPA)¶
Why it exists
- Brochure, trust, user-testing notice, and CMS-managed content without loading the Angular desktop shell for every visitor.
- Standing split: htmx/Razor for content, Angular for the product app.
Cost / benefit: clear GTM surface and staff CMS vs another deployable (and a hard requirement that QA content buckets never publish into production).
3. Strategy principles (from the contracts)¶
- Desktop first, cloud second. Server mode is opt-in via config (
Edition=server), not the silent default. - Audience is server-derived. Invitation codes and Google allowlists assign policy; the browser must not invent edition from URL or build flags.
- Short menu beats fake full product. Pilot routes are mechanically limited; config cannot unlock unsafe multi-tenant legacy stores without an explicit unlock that shares process-wide data (documented hazard).
- Separate money brakes from infrastructure bills. AI dispatch caps and GCP budget alerts are different layers; do not sell one as the other.
- One desktop artifact. No evidence of a second branded “internal desktop” installer — internal difference is cloud identity/cohort, not a second NSIS product name.
- Honest gaps. Missing
tester-laptop-distribution-spec.mdmeans laptop fleet logistics are not codified here — TODO(verify) before promising hardware-based distribution programs.
4. Cost / benefit summary table¶
| Surface | Main benefit | Main cost | Keep when… | Drop / freeze when… |
|---|---|---|---|---|
| Desktop NSIS | Full product, local trust | Build size, signing, support of EXE | Real users and power demos need full depth | N/A as core product in current strategy |
| Cloud server pilot | Review/test without install | Cloud ops, security review, short feature set | Need YC/team first look or hosted testing | If it is sold as full multi-tenant SaaS without tenant-safe stores |
| Invitation audiences (YC / team) | Policy separation without admin grants | Code ops, hash secrets, redemption limits | Distinct legal/review vs team needs | If a single shared demo account would suffice (it usually does not) |
| Google cohorts (internal / user-testing / qa) | Identity-based access + clean telemetry | Allowlist maintenance, multi-mode edge cases | Recurring humans, dual roles | If everyone is one-off invitation only |
| UserTesting flag | Learning from real sessions | Survey fatigue, PII discipline | Active tester program | Flag left on in non-test deploys without intent |
| Prod vs QA ladder | Blast-radius isolation | Double secrets/services | Any writeable CMS or tester traffic | Temptation to point QA CMS at prod bucket |
| Docs audience gates | Information control | Manifest discipline | Mixed YC + team readers | Public-all docs that never need gating |
| Marketing editions copy (desktop free / cloud subscription) | Clear story on the site | Must not over-claim live paid cloud | Narrative matches actual offer | Copy implies live subscription not yet operated — TODO(verify) monetization status |
5. What success looks like (non-revenue)¶
From cloud-edition business framing and technical contracts:
- Reviewers and teammates enter only with proper gates, get isolated workspaces where designed, and cannot open non-pilot surfaces.
- Desktop installers remain shareable for friend/tester laptops without requiring cloud tenancy.
- Spend and abuse have brakes on pilot AI paths; rollouts fail closed on wrong security topology.
- Telemetry can separate QA from user-testing cohorts.
Revenue model for cloud SKU, willingness to pay, and rolled-up monthly cloud COGS: TODO(verify) — not established as fixed numbers in the edition contracts.
6. Decision framing¶
Keep multiple editions while:
- Desktop remains the full product and cloud remains a bounded pilot (or later a clearly paid hosted SKU with tenant-safe storage).
- Audiences (YC, team, internal, user-testing, QA) still need different data, retention, or metrics rules.
- Operators can afford Secret Manager, ladder deploys, and invitation hygiene.
Collapse surfaces only when a single path meets privacy, support, and review needs without silent cross-tenant risk — and document the collapse; do not “simplify” by turning unlock flags on in production multi-tenant hope.
7. Source map¶
| Topic | Source |
|---|---|
| Desktop packaging / updater | docs/technical/packaging.md, electron/package.json |
| Server edition contract | docs/technical/cloud-run-server-edition.md |
| Cloud business case | docs/business/cloud-edition-value.md |
| Cohorts / dual-role | docs/design/wing-214-google-sso.md |
| Docs audiences | docs/cloud-docs-manifest.json, docs/technical/oauth-and-reader-tiers.md |
| Ladder hosts | ops/cloud-run/env-ladder.json |
| Marketing edition cards | src/WorkWingman.Site/Content/site-content.json |
| Release dual-edition narrative | docs/technical/wing-202-release.md, docs/plain/wing-202-release.md |