01-projects/printables-product

Scribble Works product model — founder rulings (freemium, trust ladder, feedback loop, site tree v2)

2026-08-31·decision-log·status: active
scribble-worksproduct-modelfreemiumrulings

Scribble Works product model — founder rulings, 2026-08-31 16:37 iMessage

Why this is in the vault

One founder message answered all three open storyboard questions and corrected the just-shipped site tree. This is the product model: monetization tiers, the automation trust ladder, and the feedback-loop design. Everything below is a founder ruling unless marked as Ray framing.

The [[2026-09-06-scribble-works-trust-ladder|trust ladder]] (his core strategy statement, near-verbatim)

"We want the manual version to build the playsets, then customize a game, then auto-complete a playset, then completely generate playsets. Parents slowly build trust with turning over the child's lesson plan to our service. That turns into a need for push. Otherwise the parents will burn out on it. Same way Michelle runs the risk of burning out handcrafting these games each day."

Rungs: (1) manual playset building → (2) Customize one game → (3) magic-wand auto-complete → (4) fully generated playsets. Push email is the payoff of the ladder (burnout prevention), not a growth mechanism.

Freemium tiers

Feedback loop ("plan for it")

Push AND pull distribution

Push: email with the playset (the default rhythm). Pull: parent can always download directly from the site. First-run is browse-first — no profile setup gate.

Site tree v2 corrections (supersede the PR #2 stub tree)

  1. Browse and playset-builder are ONE page — the pull-out tray is the builder.
  2. How-it-works collapses onto Home.
  3. Help → footer link named FAQ; add standard footer pages (privacy policy, terms, etc.).
  4. Portal → "Log in / Create account" with button treatment, not a nav destination.
  5. Hamburger nav on mobile widths.
  6. Catalog shows mini previews of each game; packs are scrapped from the catalog (games only). Previews depend on the thumbnail-export feature (queued).
  7. Game detail page shows a larger view of the game.

Additional rulings, 17:42 iMessage (with Home-section screenshot)

  1. Home page: highlight a few different game TYPES and share the skill each builds for kids (replaces the packs section — his words: "we should highlight a few different game types and share the skill they build").
  2. Browse page needs a better title and lists all individual games.
  3. Add-to-playset must be visible/usable (drove the playset-builder build, shipped PR #4).

Portal rulings, 2026-09-01 14:45 ET iMessage (closes the storyboard interview)

  1. Multi-kid: one household account, one profile per kid (name, age band, interests, focus skills); dashboard = one row per kid (this week's playset + last upload). Founder: "Support multi-kids. We can consider charging more per kid." Per-kid pricing = open pricing lever, not yet decided.
  2. The plan IS a screen, paid only: week view of 5 day-cards, each a playset (wand-filled, editable, "print" + "email me this" on every card). Free accounts see a single "this week's playset" card instead of the calendar.
  3. Upload → profile update: founder has NOT ruled. His framing splits it into two loops: (a) updating the individual child's plan, (b) "upping the quality across the whole service." He doesn't yet know how (b) manifests. Ray default for (a) until ruled otherwise: auto-update with undo, no confirm step. (b) = open product question; candidate for a Ray proposal, not a founder ask.

Storyboard interview status: CLOSED. Portal design round is ungated (studio queue item 18).

Reconciliation note (Ray, 2026-09-01 15:10 ET): ruling 11 above says "age band" on the kid profile; the charter (§ Child sub-profile, line ~346) says "Birthday, not an age band." Birthday wins: it is the founder's earlier, more specific ruling and the age band derives from it. Portal round stores birthday, displays age band. Flagged by the fresh-eyes strategy audit ([[2026-09-01-fresh-eyes-audit-synthesis]]).

Planner rulings, 2026-09-01 21:35 ET iMessage (after trying the live shopper page)

  1. Curation vs generation tiering (founder, Ray agreed): free / no-account = Ray curates a playset from the shelf (incl. theme variants fed back from Customize); paid = Ray generates new pages on demand. Curation is the magic moment; generation is the subscription. Reasons: per-playset cost once art is in; generated pages must pass the critic before a child sees them, so they cannot be instant.
  2. Naming: "shopper" was an internal label; the feature is the Playset planner, Ray is the planner. CTA "Plan today's playset"; form button "Assemble the playset" (founder's words). "Tutor" rejected by Ray as promising a person; founder may still pick it.
  3. Copy: headline "What does your kid need today?" replaces "Tell me about your kid."; "Set the table" removed.
  4. Chips + sentence both feed the picker; layout must say so (chips above the box, one button under both, no "or"). Chips alone can submit.
  5. Three playset doors = one funnel, in order: Planner (front door) → Ready-made playsets ("not sure what to say? start here") → The shelf (Browse, power path). All three stay. Labels: The shelf · Ready-made playsets · Plan one for your kid.
  6. Planner page was unlinked (founder had to type the URL): header link on desktop, drawer card, Home front door.

Ruling 20 — 2026-09-02 06:35–06:47 ET (founder iMessage, verbatim quotes)

Ruling 21 — 2026-09-02 08:12 ET (founder iMessage, verbatim)

"I'm not sure about my ruling for it to be household only. I thought we logged it and had an evaluation pass in the background that could promote these to the marketplace. This seems like a user-generated content (UGC) opportunity. People will be creative with their asks for customization. A lot more than we can brainstorm ourselves. It'll accelerate the marketplace buildout."

Ruling 22 — 2026-09-02 08:45 ET (founder iMessage, verbatim)

"On the retention terminology, do we have to show it so much on the page? That belongs in the privacy policy/terms of service, then the copy doesn't have to be so pronounced or included at all."

Ruling 23 — 2026-09-02 09:31 ET (founder iMessage, verbatim)

Ruling 25 — 2026-09-02 10:56 ET (founder iMessage, verbatim)

"I think before we develop that feedback feature more we should work on the account creation. Feedback could be screened for known accounts with verified emails and phone numbers."

Ruling 26 — 2026-09-02 11:08 ET (founder iMessage, verbatim excerpts)

Ruling 27 — 2026-09-02 11:22 ET (founder iMessage, verbatim)

"Okay. So start with parents/households and we can expand to teachers/schools. We will have more legal to cover and we can plan it out state by state. Teachers may use this independently, but we would treat them as a household for now." → Phasing: v1 lead parent (building) · v2 household adults + kid profiles + consent · v3 schools/classrooms later with a state-by-state legal plan. Teachers = households in the interim (no rosters, no school-sourced child data). Decision-doc agent updated accordingly.

Ruling 28 — 2026-09-02 13:22 ET (founder iMessage, verbatim)

"We should flesh out what you can do within that account page more. Add members to a household. Manage billing. Game calendar planning. All of that should be within the members area." → The /account page becomes the MEMBERS AREA (v2 scope): (1) household members (2 extra adults by invite; kid profiles); (2) billing (Stripe under Ray Data LLC = new external account, founder opens; integration prepped behind a flag); (3) game calendar planning (weekly slots per kid, auto-fill by age/interest, print the week as a playset, mark done, carry forward); (4) playsets, customized pages, feedback sent, privacy controls (export/delete). Ray: members-area spec + wireframes for founder read before build. Bug reported same message: signed-in header lacks a "Your account" link back (fix in flight).

Ruling 29 — 2026-09-02 13:41 ET (founder iMessage, verbatim)

"We can spend a cycle doing an infrastructure hardening and documentation gathering. List out our components and how they wire together. Add the CI processes and any test suite we should build to validate work before opening the PR. I don't want to compound on a shaky foundation, so taking a step back to cleanup every 5-10 PRs seems like good diligence." → Standing rule: a hardening round every 5–10 PRs (studio process; amend charter §8). This cycle: ARCHITECTURE.md (component inventory + wiring diagram + secrets map + deploy path), GitHub Actions CI on PR (build + validators + all test suites + schema guard + preflight) with required checks, pre-PR checklist for agents, then the refactor list from audit A (shared function utilities, KV counters, error monitoring, notes file).

Ruling 30 (2026-09-02 18:33 ET) - counsel is not a gate

Founder, iMessage: "Let's build it as we have planned. I can change it later if council advises otherwise. Let's not let hypothetical legal problems get in the way for now. We do our diligence to be reasonably confident we won't get in trouble. I don't want to do anything illegal, but I'm not going to walk on eggshells and pay multiple thousands of dollars before we've proven out anyone is even interested in using the product."

Applies to: the account-relationship model D0 ([[2026-09-02-account-relationship-model-decision]], counsel authorized 18:15, outreach parked 18:30, now explicitly not a gate) and the members-area v2 build ([[2026-09-02-members-area-spec]]). The child-profile UI no longer waits behind a flag for a written opinion. Diligence kept as the standing posture (D5): adult-only sign-in, no child login, every child field typed by a parent, published retention, a real consent record, no third-party disclosure, no photos of children. Counsel resumes on "ready for counsel".

Addendum (18:36 ET), founder's framing, kept as the posture statement: "This is for adults, specifically parents/guardians. The print outs are for the kid, but that is controlled by the parent physically printing out the games and handing it to them. We are not directly interacting with the kids at any point... We are also avoiding legal sensitivities by not going for teachers or school systems to start. We can tackle that later." Consequences: no school-facing or teacher-facing marketing in v2 (which also keeps Fla. Stat. 1006.1494(1)(e) out of play); classroom printing stays allowed in the terms (ruling 23); teacher/school work is v3 on the founder's call.

Ruling 31 (2026-09-02 18:44 ET) - the tier line is curation, and delivery is the paid product

Founder, iMessage: "free authenticated can get a two week rolling plan, but must self-curate those playsets... AI-curation and customization (pre-filling those playsets based on your child's education plan) is a paid plan. We send the playsets in an email or sms and a paying parent might never have to come back to the website, but could be getting lots of value for their children."

Reads on top of rulings 20 and 26. Signed-in free: the rolling two-week plan, history, feedback, and the whole shelf, filled by hand. Paid: playsets pre-filled from the child's profile and focus topics (code selection plus gateway customization), delivered by email (SMS once Twilio exists) on the plan's schedule; the site is optional for a paying parent. This is charter rung 4 (scheduled delivery) as the product. Supersedes [[2026-09-02-tier-line-plan]] Decision 1's default ("shelf-filled two-week plan free"): the plan is free, the filling and the sending are paid. Nudge N1 (tomorrow's playset, see [[2026-09-02-retention-nudges-plan]]) becomes the delivery itself for paid households.

Ruling 32 (2026-09-02 18:52 ET) - release as they pass

Founder, canonical AMEND on the [[2026-09-02-audit-synthesis]]: "In general, okay to release these games as they pass the critic and continue iterating on the ones that don't." A game goes live when the PDF gate (audit [[E-pdf-gate-batch]] contract) passes; a game that fails stays pending and iterates. No batch holds. Same decision: no counsel authorization, no USPTO look ("not mature enough yet").

Ruling 33 (2026-09-05 03:37 ET) - daily playset is one packaged PDF, not six links

"I also did not expect this to be 6 individual games. It should be a single packaged playset, including the 7th title page that is for the parent. So there needs to be some process, maybe curate/customize - package playset - send email. Are we capturing which games were sent in previous days, because we want to minimize the repeats. That detail should be fed in during the curate/customize step."

Operative: the paid delivery motion is a three-step pipeline curate/customize → package → send. The delivered object is one PDF per kid: parent-facing title page first (what's inside, what you'll need, Ray's line), then the six game pages. The email is a designed surface per [[DESIGN-scribble-works]], not a list of links. Repeat history (the deliveries log) is an input to the curate step (14-day exclusion, least-recently-sent fallback marked "a favorite again"). Same-day: "the visual style of this email could be spruced up more." Build brief: ~/.claude/state/studio/dispatches/2026-09-05-daily-playset-v2-package-and-email.md.

Ruling 34 (2026-09-19 09:53 ET) - hand-lettered text in generated icons is allowed; UGC text is screened

Founder, verbatim: "Hand lettered writing is fine. That looks great. Just have to ensure they don't say anything bad if generated by UGC."

Operative: model-drawn letterforms inside generated art (e.g. the Quiver "BOO!" sign and "RIP" tombstone in halloween-scavenger-hunt, PR #321) are acceptable on studio-authored printables. This narrows the [[2026-09-01-customize-spec]] line 61 rule ("letterforms stay code-drawn") to instructional text: labels, numerals, answer keys, and anything a child reads to do the task stay code-drawn; decorative lettering that is part of a picture may be model-drawn. On any UGC-facing rail (customize-art, hosted Iterate), rendered text must pass a moderation screen before it ships (queue item 2026-09-19, engineering M). Context: [[2026-09-19-icon-set-bakeoff-quiver-vs-grok]].

Ruling 35 (2026-09-19 09:53 ET) - scavenger hunt is a game type

Founder, verbatim: "Scavenger hunt is absolutely an acceptable new game type."

Operative: add activity: scavenger_hunt to the taxonomy (the ≥5-pages threshold for a new value is waived here by the founder) and move halloween-scavenger-hunt from matching to it. First instance: PR #321, merged 4baa7d9 by the founder 2026-09-19 09:53 ET. Shape: title + instruction, 2x6 grid of checkbox + icon + bilingual label, no answer key.

Ruling 36 (2026-09-19 10:03 ET) - art detail is a dial with per-surface defaults

Founder, verbatim: "Can we give it an effort dial? We may not want simpler in all cases. Basically if I tell you more detail or less detail I don't want the hardcoded simpler constraint in there. We can have a reasonable default. Perhaps the defaults are different for different places. Simple for a game with multiple pieces, but more detail is fine if we have a full page coloring sheet. Even more detail is fine if we are looking to use an asset on the website."

Operative: generated art carries a detail stop (simple / standard / rich). Defaults: multi-piece game icons = simple; full-page coloring sheet and scene art = standard; website assets = rich. An explicit founder instruction moves the dial and is never overridden. Contract text in [[DESIGN-scribble-works]] amendment 2026-09-19; critic reads the declared stop. Engineering follow-up queued: --detail parameter on the art prompt composers with those defaults by slot class.

Addendum to ruling 36 (2026-09-19 10:51 ET): founder confirmed the scene default after the smoke evidence: "Sounds reasonable to not keep the coloring pages too simple." Full-page coloring sheets default to standard; simple is for multi-piece icon pages. Plan issue: RayDataCo/scribble-works#324 (added to the GitHub Project by the founder 10:51 ET).

Ruling 37 (2026-09-19 16:20 ET) - agent usage gets its own lane, under a global household cap

Founder, verbatim: "Agreed agent usage has its own lane, but global usage caps for a household."

Operative: agent-originated calls (Muse connector, MCP clients, any service credential) are rate-limited and budgeted on their own keys, separate from the human browser lane, but every call debits one ledger per household. The household cap is the ceiling for human + agent combined. Same message: plan an agent authentication strategy (asked whether better-auth has an agent story) and plan server + client utilities (serve via MCP and skills; turnkey client onboarding). Plan issues: RayDataCo/scribble-works#333 (amended) plus two new issues filed 2026-09-19 afternoon.