Ian + Barbara

Open decisions

Every choice we need to make to move Snupix forward — de-duplicated from the full plan into one place. Each card states the question, why it matters, the real options, and a recommendation. The two true go/no-go items are A1 (commit) and G1 (co-founder terms).

★ Decide firstunblocks everything downstream ·Ratify baselinealready resolved — confirm or override ·Forwardreal, but not urgent now

Decide first

6 that gate the most work

1Brand

Brand permanence (name + bright-vs-darkroom)

"snupix" sits one letter from "snoop" and fights the safety wedge; the bright/fun beta palette also diverges from the prior editorial-darkroom direction. Both are now live questions and unblock the domain, logo, store reservation, and the landing rebrand.

Lean: OnSet (pending TM/domain); adopt the bright/fun direction as the brand of record for the consumer surface, retire the darkroom unless a clear reason returns it.

F1 / §6

2Trust & Safety

Image hosting — the CSAM trigger

The single load-bearing safety call hidden in the beta: the instant Snupix HOSTS or CACHES a user image, the federal CSAM-reporting duty (18 U.S.C. §2258A) attaches — phase or no phase. Embed-only keeps the duty at its narrowest.

Lean: Embed-only via the user's own authorized IG render, no caching, for the first shoots. If any hosting/caching/manual-upload is wanted, a PhotoDNA hash-match + NCMEC path must be in before the first stored image. Decide this first.

Beta §9.1 / E3 / §7.4

3Beta

Instagram-embed ToS path

The clean way to show "4 most recent posts" changed: legacy oEmbed is deprecated and Meta is mid-migration off Basic Display. The handle-hidden / no-link-out rule may also collide with attribution requirements. This is the #1 thing to verify before building.

Lean: Time-box a half-day spike on the user-authorized pull (render-our-own, suppress handle + permalink); ship manual-photo-optional as the universal fallback if blocked. The beta does not depend on IG embedding to function.

Beta §2.2 / §9.2

4Beta

Retention threshold

The 40–50-participant gate decides whether to build the native app + open the marketplace. But "coming back" has to be defined before you gate on it.

Lean: Primary signal = % of beta participants who register for a 2nd shoot via the app, with a named threshold (e.g. ≥30–40%); set it with Barbara before the gate.

§4 / §9.3

5Scope

The 5 "Maybe" features

Five features sit on the borderline in the tracker (F-O-CENSUS, F-106, F-D07, F-D10, F-413). The closest call is the consent / boundary checklist (F-106) — the highest-safety-weight item currently outside V1, right beside the in-person primitives that were pulled in.

Lean: F-106: lean YES into V1 if it can ship as a static templated checklist; keep it V2 if it needs the full release engine. The other four resolve in the interactive tracker.

C3 + 4 more (5 "Maybe")

6Strategy

Calendar vs. liquidity gate (SF → LA)

Barbara's "SF 6 months, then LA" is a calendar; the canon's expansion trigger is a liquidity/retention gate. They usually agree — but if SF hasn't proven retention by month 6, which one wins?

Lean: Keep "6 months" as the aspiration but let the retention gate win — never move to LA on a date if SF hasn't proven repeat participation. Premature geo expansion is the #1 marketplace killer.

Beta §5 / §9.4

Strategy

4 decisions

Go / no-go, intensity, the cold-start sequence, and how far the beta expands.

A1★ Decide first

Commit to Snupix, and at what intensity?

Why it matters. Ian runs multiple parallel bets. Snupix is a full, safety-gated product — it can't be a nights-and-weekends afterthought and be safe. It also spends a real person's time now (Barbara).

aFull commit — treat it as a primary bet; build V1, run the SF launch.
bTime-boxed validation sprintrec — ratify brand + co-founder terms, run the census, confirm the IP path, stand up the single-player core, then a hard go/no-go gate before the expensive safety build.
cPark — keep the landing warm, revisit after a current bet resolves.

Recommendation. The host-curated beta IS this validation sprint. Running real shoots from late July is the live test; its retention gate becomes the explicit go/no-go for the open-marketplace + native build.

B1★ Decide first

Primary cold-start segment + the operating rule

Why it matters. Dictates who you hand-recruit, what single-player value you build first, and how every marketing surface reads. The research looked split (photographers-first vs models-first); it resolves into one sequence, not a winner.

aPhotographers-first — abundant posting supply, but risks a glut models never arrive for.
bModels-first — the demand magnet, but worthless until trustworthy photographers exist.
cThe synthesis sequencerec — seed photographers, launch a ~50/50 balanced cohort, then bias growth to quality models and design model-trust-first.

Recommendation. Seed the side you can't conjure (photographers); over-serve the scarce trust-constrained magnet (models). Lead consumer copy with the model's safety pain; lead seeding ops with photographer throughput.

Sizing posture for investors / co-founder talks

Why it matters. A liquidity-gated marketplace lives or dies on local density. Leading with a top-down $254B TAM invites the wrong (premature-scale) conversation.

aBottom-up SOM + North Starrec — lead with the nameable seed list (~6,000+ verified Bay Area memberships + Barbara's network); TAM as the ceiling only.
bTAM-first — undercut the moment anyone digs into the tiny formal-labor numbers.

Recommendation. Bottom-up SOM density + the North Star; show TAM only as the pie. Reject TAM-first unless pitching a pure top-down VC.

B4Forward

When does SF graduate to start LA?

Why it matters. Premature geo expansion is the #1 marketplace killer — each metro is a fresh cold-start, not expansion. Model Mayhem and the long tail tried to be everywhere and were dense nowhere.

aLiquidity-gatedrec — SF self-sustaining ≥6 weeks without founder hand-hosting + 8–15 open Briefs + rising North Star + clean safety record.
bRevenue-gated — Barbara's bootstrap instinct — useful as a secondary confirmation.
cCalendar-gated — reject — dates don't make a market dense.

Recommendation. Liquidity-gated primary, revenue as secondary confirmation; never on a date. Forward decision, not urgent now.

Beta

4 decisions

The host-curated IRL beta Barbara is driving from late July: the ticket, the fast profile, two pings, and the retention gate.

§2.2★ Decide first

Verify the Instagram-embed path before building

Why it matters. Optional "connect Instagram → 4 recent posts, embedded" is core to the fast profile, but the ToS-safe display path is genuinely in flux (oEmbed deprecated, Basic Display mid-migration). The no-handle / no-link-out rule may collide with attribution.

aUser-authorized pull (A)rec — OAuth the user's own IG, render our own gallery, suppress handle + permalink. ToS-clean, exactly 4 recent posts.
bOfficial oEmbed (B) — carries IG branding by design — conflicts with 'protect the relationship'.
cManual upload fallback (D)rec — universal fallback so IG is never a hard blocker.

Recommendation. Pursue (A) as primary with (D) as the universal fallback, but treat Meta API availability + caching/attribution terms as a pre-build verification gate. Do not assume oEmbed just works — it doesn't anymore.

§4★ Decide first

The exact retention threshold + metric

Why it matters. After 40–50 people have participated, retention decides the native-app build. But you must define "coming back" before you gate on it — the same discipline as the canon's "advance on the metric, never the calendar".

a2nd-shoot registrationrec — % of beta participants who register for a second shoot through the app — the strongest 'come back on their own' signal.
bOrganic in-app action — % who open / re-register without Barbara prompting — a supporting signal.
cApp-opens — reject as the gate — opening once isn't the outcome (repeat real-world participation is).

Recommendation. Define it with Barbara before the gate: primary = "% who register for a 2nd shoot via the app", with a named threshold (e.g. ≥30–40%).

§1

What is "the ticket", exactly — and is it gated?

Why it matters. The beta's whole motion is "the app is literally the ticket in." Is registering through the app required to attend, or just the best way to get details? This is what generates the install + the retention measurement.

aTrue gaterec — registration required to attend — drives installs and the retention signal; keep a manual fallback so no one is turned away at a real event.
bSoft / details-only — lower friction, but loses the install funnel and the measurement.

Recommendation. Make it the genuine gate, with a manual fallback for app glitches. The install + retention measurement depend on it.

§2.1 / §9.9

Role tagging in the fast profile

Why it matters. Barbara's bar is "no labels" for the beta. But the open phase needs photographer/model roles — do we silently capture a tag now, or truly nothing?

aCapture silently, show nothingrec — store a soft optional role tag, render no labels in the beta UI — honors 'no labels' visibly without throwing the data away.
bTruly nothing — purest reading of 'no labels', but re-collects roles later from scratch.

Recommendation. Capture a soft optional tag silently; show no labels in the beta UI. Honors the rule, keeps the data for V1 roles.

Trust & Safety

5 decisions

The existential category. Several items are launch-blocking P0 legal floors, not preferences — build as if the lawsuit is coming.

§7.4 / E3★ Decide first

Does the beta HOST/cache user images, or embed-only?

Why it matters. The beta's biggest legal decision. The instant Snupix stores a user-supplied image, the federal CSAM-reporting duty attaches (18 U.S.C. §2258A / REPORT Act) — this is the one canon P0 item that can become launch-blocking inside the beta.

aEmbed-only (no caching)rec — render the user's own authorized public IG; the hosting duty is at its narrowest. Still publish a content policy + report path.
bHost / cache / manual upload — needs a PhotoDNA hash-match baseline + quarantine-and-preserve + an NCMEC reporting route before the first stored image.

Recommendation. Embed-only for the first shoots — the cheapest safe beta avoids hosting images entirely. If hosting is wanted, the CSAM + NCMEC path is in before the first stored image, full stop.

D0Ratify baseline

The ONE ID / age policy (action-gated)

Why it matters. The first cut carried two conflicting rules (ID-to-host vs ID-for-all-photographers). They collapse into one action-gated rule every doc now uses — stricter where physical risk is created, looser where it isn't.

aAction-gated (the baseline)rec — 18+ facial age-estimation for everyone at signup; no ID to browse/match; FULL document ID before you HOST or ATTEND an in-person shoot; badge on ID completion.
bRole-gated — superseded — tied ID to role, not to the action that creates risk.

Recommendation. Ratify the action-gated baseline. The shape is fixed across all docs; only the friction thresholds (D1) are tunable.

D3★ Decide first

Nudity / boudoir content stance for V1

Why it matters. TFP legitimately includes implied-nude / boudoir — but allowing it collides with Apple 1.1.4 + Google Inappropriate Content and massively raises the CSAM + age risk during the fragile launch.

aHard-ban all nudity/implied — safest for store survival; narrows the market.
bAllow fashion/lingerie/implied, ban explicit — bigger market, much higher review + moderation risk.
cBan for V1, revisit laterrec — clothed/fashion/editorial/portrait only at launch; reconsider as a gated, ID-verified, separate surface.

Recommendation. No nudity / implied for V1. An explicit no-nudity line protects store standing and shrinks the CSAM surface; the NSFW classifier (F-030) enforces it.

Takedown / safety-report SLA targets

Why it matters. A report button without a response SLA fails Apple 1.2 "timely response" and FOSTA-SESTA's posture; §3344 has a statutory 2-business-day removal clock.

aTiered SLArec — 24h for safety reports / 48h for other content at launch; §3344 floor = 2 business days; CSAM = immediate quarantine + auto-report, no human-review delay.
bBest-effort — fails the 'timely response' bar and the litigation posture.

Recommendation. Ratify 24h safety / 48h other / 2-day §3344 / immediate CSAM. Tighten as volume grows; this binds the moderation staffing (D5).

Who runs moderation + the NCMEC pipeline?

Why it matters. The instant users upload photos, CSAM detection + NCMEC reporting is a federal duty — knowing failure to report is a crime. The tooling is net-new; the runbook (who reviews, who's the registered contact) has no default.

aFounders cover the rota — low volume, but real on-call burden + legal seriousness.
bContracted service from day one — removes the burden, costs more before there's volume.
cHybridrec — automated pipeline auto-reports CSAM hash hits (no human in the loop); a named human owns the report queue; escalate to a service if volume grows.

Recommendation. Hybrid. The CSAM auto-report path must be fully automated; a named human owns the queue + NCMEC ESP registration. This is also the founder-governance call (G5 — the T&S officer-of-record).

Brand

3 decisions

The name and the look must do safety-positioning work — read serious and creative, never 'hot models' or hookup.

F1★ Decide first

The consumer brand name

Why it matters. The name must repel creepy demand, survive App Store review, and attract quality supply. "snupix" sits one letter from "snoop" (surveillance/creep), which actively fights the safety wedge. The repo slug stays snupix regardless.

aOnSetrec — outcome-framed ("the shoot happened" = the North Star), creative-industry-native, short, safe, no consumer collision found. Pending TM/domain.
bCapa / a coined pick — heritage (Robert Capa) or pure ownable whitespace (Cadra / Lumora).
cKeep snupix — preserves waitlist equity + playful tone; if kept, lean into a warm, safe identity to neutralize the 'snoop' shadow.

Recommendation. OnSet — best single alignment to the trust/execution wedge. If changing, run formal TM (USPTO class 9 / 45) + domain + store-name clearance on the top 1–2 before committing.

§6Ratify baseline

Bright/fun palette — permanent, or beta-only?

Why it matters. Barbara's direction is simple, bright, clean, one bold accent (coral/orange lead, switchable), fun + approachable. It diverges from the prior "editorial darkroom" (near-black, single amber, deliberately calmer). Someone must decide if bright becomes permanent.

aAdopt bright as the brand of recordrec — it fits the host-curated, come-shoot-with-us community motion far better than a moody darkroom.
bCoexist by phase — bright for the community beta, darkroom revisited for the open/native app.

Recommendation. Adopt bright/fun as the brand of record for the consumer surface; retire the darkroom unless a clear reason returns it. Settle alongside F1. Anti-hot-or-not discipline still binds regardless of palette.

F3Ratify baseline

Anti-hookup / anti-hot-or-not discipline

Why it matters. A policy-survival position, not just marketing — Apple 1.2 can remove "objectification of real people (hot-or-not voting)" apps without notice. It binds the name, icon, screenshots, swipe copy, and store description.

aCollaboration framing everywhererec — every review-facing surface reinforces collaboration matching; the swipe is "Pass / Collaborate" word-buttons, never ✕ / ♥.
bRomance/rating affordances — reject — invites Apple 1.2 removal and the wrong audience.

Recommendation. Ratify as a hard brand + policy guardrail (binds F1 and all UI copy). Also fix the landing page's ✕/♥ swipe and the fabricated hype stats (10K / 500 / 4.9★).

Scope

5 decisions

The V1 cut-line and the borderline features. The fine-grained In/Maybe/Out calls live in the tracker.

C1Ratify baseline

Ratify the V1 cut-line

Why it matters. V1 scope is the build plan. MVP-SCOPE draws the line by one test per feature: does removing it break the loop, the North Star unit, or the safety/legal floor? IN if yes; deferred to V2 if it merely deepens a working loop.

aHold V1 to the MVP-SCOPE IN listrec — the single core loop + the full P0 legal/safety floor + the three in-person safety primitives + minimum analytics. The one genuine borderline is C3.
bRe-open the line — cascades across multiple docs — don't silently re-open a baseline.

Recommendation. Ratify the cut-line as the build target. Propagate the safety-primitives-in-V1 placement (F-110/111/205) back into FEATURES.md so the catalog matches.

C3★ Decide first

Pull the consent / boundary checklist (F-106) into V1?

Why it matters. The highest-safety-weight item currently outside V1, sitting right beside the three in-person primitives that were pulled in. It's the model-side existential pain (wardrobe/nudity boundaries, touch, retouching) — but the matrix files it V2.

aPull into V1 (if static)rec — a static templated checklist is low-build, high model-trust, on-brand — and the model side's adoption trigger when reliability signals are still empty at launch.
bKeep V2 (if it needs the engine) — ship in the first post-launch sprint if it requires the full release-template engine to be meaningful.

Recommendation. Lean yes into V1 if it can ship as a standalone static form; keep it V2 if it needs the full release engine. The closest borderline on the cut-line — Ian's call.

Brief prescriptiveness (how hard-required are TFP terms?)

Why it matters. The Brief is V1's richest primitive. How prescriptive it is determines whether the Delivery tracker (and later the Reliability ledger) are enforceable against a stated promise — or just nags.

aSoft defaults — lowest friction; nothing is enforceable.
bHard-required fields — fully enforceable; nags hobbyists about wardrobe minutiae.
cHybridrec — hard-require the four trust-load-bearing fields, soft-default the rest.

Recommendation. Hybrid. Hard-require delivery date, delivery count, usage-rights scope, and release expectation; soft-default everything else.

Instagram interoperability depth at V1

Why it matters. IG is the trust touchpoint creatives already vet by ("no IG reads as not real") and the distribution channel the flywheel parasitizes. Deep two-way posting is brittle and an App-Store risk.

aImport-only — lowers onboarding friction, supplies a trust signal.
bImport + share-card exportrec — import for onboarding + one-tap share-card export to power the flywheel.
cDeep two-way auto-post — skip — brittle and a store risk (REEL/BuddyUp prior art).

Recommendation. Import + one-tap share-card export; skip auto-post. This also settles the export half of the share card (F-026).

V1 AI matching depth

Why it matters. AI is infrastructure, not positioning (Promodeling led with AI → zero traction). The build cost of real ML is real, and §3344 forbids ever generating a likeness.

aFull ML style-matching — real build cost, not required to prove the loop.
bSimple ranking heuristicrec — style-tag overlap + radius + recency; proves the loop, upgradeable post-launch.
cNone / pure filters — leanest, but loses the soft surfacing.

Recommendation. Simple ranking heuristic for V1. Never market-lead with it; AI must only match real likenesses, never generate one.

Feature-level calls live in the tracker

This page holds the strategic forks. The fine-grained In / Maybe / Out call on each individual feature — including the 5currently marked "Maybe" (F-O-CENSUS, F-106, F-D07, F-D10, F-413) — is editable, draggable, and savable in the interactive tracker.

Open the tracker →