01-projects/printables-product

Scribble Works strategy and spec audit (fresh eyes, 2026-09-01)

2026-09-01·audit·status: live
scribble-worksauditstrategy

Scribble Works — strategy and spec audit (fresh eyes, 2026-09-01)

Scope: six documents only (charter [[2026-08-31-studio-charter]], [[2026-08-31-product-model-rulings]], [[2026-09-01-engine-build-spec]], [[2026-09-01-recommended-playsets-spec]], [[2026-08-31-marketplace-taxonomy-proposal]], studio queue). No UI audit. Blunt by instruction.

Headline: the body of work has built a credits ledger, a generative engine, a corpus scheme, a freemium ladder, and a paid week-view plan on top of exactly one observed behavior: one mother hand-making six games a day for one three-year-old. No document contains a mechanism to learn whether any second household prints twice. The charter's own §7 said this, the founder never read it, and everything written since has moved further away from it.


1. Coherence check — contradictions and unstated load-bearing assumptions

1.1 The charter is officially OPEN and unread, yet every later document treats it as law

The founder's 09:36 message ("trying to up our build time without my intervention, especially overnight") is a de facto greenlight, but nobody wrote the resolution. Every role boundary, escalation line, and the QA gate map are being enforced from a document the founder has not accepted. When he does read it, anything he amends has already been built against.

1.2 Child profile: birthday vs age band — direct contradiction, and the portal round is ungated

The design round that instantiates the profile is ungated with the field unresolved. Also notice the charter's languages + dominance and per-skill progress (introduced / practicing / secure) fields vanished from ruling 11 entirely. Nobody noted the drop.

1.3 The second loop the founder wants is prohibited by the privacy stance he confirmed

(b) is, by definition, cross-household aggregation of upload data. Uploads are photos of marked-up pages: the child's handwriting, frequently the child's name (kids write their name on worksheets), the parent's handwriting, whatever is on the table. This is the most sensitive artifact in the whole system and it is the one earmarked for aggregation. Neither document acknowledges the collision. See §4 for how to thread it; the point here is that it is unstated.

1.4 The paid plan consumes ~30 games per kid per week; the catalog has 14

A paid subscriber exhausts the entire catalog inside the first week. The only way the week view is fillable is rung 4 (fully generated) by default — which the trust ladder says parents must "slowly build trust" toward. The paid product as specified skips the ladder it claims to climb. Nobody has written the number 30.

1.5 Age range 3-10 vs a catalog and taxonomy that are all preschool

De-toddlering the copy while the product is 100% toddler is exactly the mismatch a 7-year-old's parent will notice in ten seconds.

1.6 "Work self-arrives" vs a queue that is entirely founder iMessage rulings

1.7 Instrumentation is on the critical path and absent from the queue

1.8 Build order is inverted: credits before accounts before any Customize user

"Billing last, post-cohort signal" and "prepaid credits this week" are in the same file. The engine is a supply-side build with zero demand-side evidence; the founder's own ruling at 19:35 ordered it the other way.

1.9 Charter tier-2 text is superseded but not amended

1.10 Cost model measures the wrong unit

1.11 "Launched" is undefined, so the kill clock may never start

1.12 Smaller items


2. The riskiest unvalidated assumption, and the cheapest test

Assumption: that the daily-playset rhythm is a parent need and not Michelle's idiosyncrasy — i.e., that a parent other than the founder's wife will print a second playset without being asked.

The trust ladder's whole engine is stated in the product-model: "Otherwise the parents will burn out on it. Same way Michelle runs the risk of burning out handcrafting these games each day." Most parents never handcraft; there is no habit to burn out on, and therefore no felt need for push. Every downstream artifact (freemium caps, credits, week-view plan, push email, upload loop, corpus economics) assumes repeat printing exists. n=1, and that one is the co-founder.

Cheapest experiment (this week, zero build):

  1. Hand each cohort household (sister ×2 kids, teacher, neighbor) one printed 7-page playset and the browse URL. Do not explain the product. Do not create accounts.
  2. Say one sentence: "Text me a photo of any page when it's done." That is the upload loop, run over iMessage.
  3. Measure three things over 7 days: (a) did they print a second playset unprompted (ask on day 7 if no signal), (b) did any photo arrive, (c) did anyone mention the title page. Also note which kid ages are in the cohort; if none are 6+, the 3-10 claim stays untested.
  4. Pass bar: 2 of 4 households print again within a week. Fail: the plan/push/credits stack gets deferred until the first-print experience itself is the work.

Second-cheapest and worth running in parallel: on the same four printers, does the low-ink claim hold and do the PDFs render clean (footers, cut lines)? Nobody has printed on a non-household printer.


3. Queue critique — re-ranked by leverage toward "prints, comes back, pays"

Rank Item Why here
1 (MISSING) Cohort onboarding + return instrumentation Nothing else can be learned without it. First-party download counting on R2/Pages (no child profile exists at tier 1, so the privacy rule permits it) + the §2 hand-delivery test. Owner: growth.
2 P1 new-game production, re-aimed Catalog depth is the hard cap on a second visit (14 games = 2 playsets before repeats). Bias to ages 5-8 and to the "unrollable sets" the playsets spec identified. Four-per-night is the plan; one-per-night is the observed rate — fix the rate before adding surfaces that consume games.
3 Item D — mobile nav visibility bug at 375px Parents arrive on phones. A nav that "reportedly not VISIBLE at 375px" is a first-print blocker, not polish. Verify on a device today.
4 Item 2 — playset title page template The charter's own trust artifact ("a straight answer to 'why these pages, in this order'"). It is the one thing that distinguishes this from free supply, and it ships on every print.
5 Item 20 — footer-free PDFs / clean "N of 7" The object in the parent's hand. Small, and it compounds across every print.
6 R2/R3 — recommended playsets, but two sets not five Cuts choice paralysis on first print. Ship "First Day of School" and "Learning to Read"; the other three are 60% the same games and make the shelf look thin. Add age band to the data shape first.
7 Round B layout + item 13 copy sweep First-visit comprehension: what is this, for what age, what does my kid get. Fold Home game-type highlights in.
8 Item 17 Customize, as concierge The differentiator, but run it Wizard-of-Oz for the cohort: parent texts "make the dino one about trucks for Maya," Ray generates on Max, sends the PDF. That validates whether anyone asks before the engine is productionized.
9 Item 24 — deterministic pre-check layer Pure throughput: catches dumb failures before a critic burns capacity. Directly raises the games-per-night rate.
10 Items 3 + 4 — USPTO check + domain prices Cheap, promised, and "clearance precedes visibility" is correct. Keep them cheap.

Over-invested (relative to evidence):

Missing entirely:


4. The second loop — how uploads could raise quality across the whole service

Precondition for all three: an explicit opt-in on the upload page ("help us improve the games — we keep what we learn, not the photo"), storage of derived facts only (game slug, age band, outcome fields, note text with names stripped), and the photo deleted after extraction. That is the only shape that survives the charter's "not aggregated across households" line; amend the charter to say so rather than pretending the loop doesn't need it.

Mechanism A — Field critic: parent margin notes become studio findings

Mechanism B — Broken-game detector / completion calibration

Mechanism C — Progression priors for the wand and recommended sets

Order: A now (manual via iMessage, then the upload page), B's schema now and its aggregation when uploads per game pass five, C schema only.


5. Three things to kill or defer

  1. Defer item 23 (production engine + Unified Billing + credits + $5 flip) until a non-household parent has asked for a customized game; run Customize as a concierge on Max for the cohort instead.
  2. Defer item 18 (portal / paid week-view plan) until repeat printing is observed and the catalog can fill more than one week without repeats; the design will otherwise encode the birthday-vs-age-band contradiction and a 30-games-per-week promise the product cannot keep.
  3. Kill item 25 (frozen-scenario eval harness for design-contract edits) and shelve items 12 and 15; process and filter infrastructure for a 14-game catalog is the "machinery becomes the work" failure the charter's §7 predicted.