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. Ian + Barbara resolved most of these at the July 1 co-founder meeting — resolved calls carry a green “✓ Decided” badge and a one-line outcome; the summary is just below.

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

Resolved · July 1 co-founder meeting

15 calls made

✓ Name

Kept the current name; OnSet dropped (memorable, contains “pix”). The .app domain was noted available.

✓ Theme + color

Bright/light adopted as the brand of record; coral accent (yellow too Bumble-like, pink too gendered). Light/dark toggle a possible future option.

✓ Instagram

Show 6 recent/pinned posts via a user-authorized pull; profile photo set separately + persists; connecting IG is optional.

✓ Image hosting

Embed-only; the app self-hosts only capped (~1MB), auto-moderated profile photos. Strictly no nudity.

✓ Reviews

Thumbs-up (not stars); two moments to give one (post-shoot + post-delivery); surface higher-thumbs users. Double-blind / 7-day reveal rejected — small community.

✓ Roles

Show Model / Photographer labels from the start; expand to makeup artists, stylists, brands later.

✓ Dual-role accounts

Deferred — single role per account initially. Phone verification enforces one account per person.

✓ Age policy

Self-declaration only for the beta — no ID upload to start.

✓ Consent checklist (F-106)

Simplified + deferred; Uber-style optional preferences if built.

✓ Retention gate

No hard gate for the beta — read repeat participation from feedback + intuition, not a 30–40% metric.

✓ Native app

Web-first (Next.js + Capacitor); native deferred until beta success.

✓ In-app messaging

Deferred pending real customer feedback (full chat vs SMS triggers; BuddyUp Twilio number reusable to prototype).

✓ Model release

Photographer uploads their own agreement; the app triggers a yes/no SMS confirm — platform handles comms only, no legal liability.

✓ Cold start

Seed 5+ photographer friends first, then group events (~7–10 models, 2–3 photographers); launch channels (Academy of Art SF, agencies, social clubs) close together.

✓ Scope / commitment

Run as a side project for now; most investment to marketing. Co-founder agreement to be discussed soon; open to a third person post-pre-launch.

Decide first

6 that gate the most work

1Brand

Brand permanence (name + bright-vs-darkroom)

✓ Decided · Jul 1 co-founder meeting. Name kept (the current name is confirmed — memorable, contains “pix”, no better alternative found); OnSet dropped. Bright/light adopted as the brand of record with the coral accent (yellow rejected as too Bumble-like, pink as too gendered). A light/dark toggle is a possible future option.

"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.

F1 / §6

2Trust & Safety

Image hosting — the CSAM trigger

✓ Decided · Jul 1 co-founder meeting. Embed-only for Instagram; the app self-hosts profile photos only, capped ~1MB, with automatic image moderation and a strict no-nudity rule. Moderation/NCMEC: follow the recommended automated pipeline for now, revisit if it becomes a real issue.

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.

Beta §9.1 / E3 / §7.4

3Beta

Instagram-embed ToS path

✓ Decided · Jul 1 co-founder meeting. Show the 6 most-recent (or pinned) IG posts via a user-authorized pull; the profile photo is set separately and persists even if Instagram changes. Connecting Instagram is optional (~5% of pros keep portfolios private — don't block them).

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.

Beta §2.2 / §9.2

4Beta

Retention threshold

✓ Decided · Jul 1 co-founder meeting. No hard retention gate for the beta. A 30–40% bar was judged too high/prescriptive this early; read the signal from intuition + user feedback rather than a fixed metric.

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.

§4 / §9.3

5Scope

The 5 "Maybe" features

✓ Decided · Jul 1 co-founder meeting. F-106 simplified and deferred (kept out of V1). If built later, model it on Uber's optional in-ride preferences — easy to dismiss, never required.

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.

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✓ Decided

✓ Decided · Jul 1 co-founder meeting. Run it as a side project for now given both founders' full-time jobs; revisit if it needs to scale significantly. Most investment goes to marketing over dev. Co-founder agreement to be discussed soon; open to a third person post-pre-launch.

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✓ Decided

✓ Decided · Jul 1 co-founder meeting. Seed photographers first (recruit 5+ trusted photographer friends), then run group events (~7–10 models, 2–3 photographers), organized manually at first. Launch growth channels — Academy of Art SF, modeling agencies, and social-club events — close together so supply and demand arrive at once (log in with no matches = drop-off).

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✓ Decided

✓ Decided · Jul 1 co-founder meeting. User-authorized pull confirmed; show 6 recent (or pinned) posts; connecting Instagram is optional. The separately-set profile photo persists even when Instagram updates.

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✓ Decided

✓ Decided · Jul 1 co-founder meeting. No named threshold for the beta — 30–40% was judged too high this early. Read repeat participation by feedback + intuition rather than gating on a prescriptive metric.

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✓ Decided

✓ Decided · Jul 1 co-founder meeting. Keep the app as the genuine ticket. Requiring the app to coordinate a shoot is a reasonable ask (like a payment method or a signed form) — exclusivity is part of the hook.

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✓ Decided

✓ Decided · Jul 1 co-founder meeting. Reversed — show Model / Photographer role labels from the start; expand to makeup artists, stylists, and brands later. (The founders chose visible role tags over the 'no labels' bar.)

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✓ Decided

✓ Decided · Jul 1 co-founder meeting. Embed-only for Instagram; the app self-hosts only capped (~1MB), auto-moderated profile photos with a strict no-nudity rule. The recommended automated CSAM pipeline + a named human owns the queue for now.

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.

D0✓ Decided

✓ Decided · Jul 1 co-founder meeting. For the beta: age self-declaration only — no ID upload to start. Phone verification enforces one account per person and adds a trust signal; AWS selfie↔profile face-matching (from BuddyUp) is a future high-trust layer.

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✓ Decided

✓ Decided · Jul 1 co-founder meeting. Confirmed — strictly no nudity, enforced by automatic profile-image moderation.

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).

D5✓ Decided

✓ Decided · Jul 1 co-founder meeting. Follow the recommended hybrid pipeline (automated CSAM detection + a named human on the queue) for now; revisit if it becomes a real issue at volume.

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✓ Decided

✓ Decided · Jul 1 co-founder meeting. Keep the current name; OnSet dropped (memorable, contains “pix”, no better alternative found). The .app domain was noted as available. Lean into a warm, safe identity to neutralize the “snoop” shadow.

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.

§6✓ Decided

✓ Decided · Jul 1 co-founder meeting. Adopt bright/light as the brand of record (feels open, inviting, collaborative — like Upwork's beige; dark suits solo portfolios). Coral accent chosen (yellow rejected as too Bumble-like, pink as too gendered). A light/dark toggle is a possible future option.

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✓ Decided

✓ Decided · Jul 1 co-founder meeting. Keep out of V1 — simplified and deferred. If built later, model it on Uber's optional in-ride preferences (easy to dismiss, never required).

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.

C2✓ Decided

✓ Decided · Jul 1 co-founder meeting. Release/agreement approach: the photographer uploads their OWN agreement and the app triggers a simple yes/no SMS confirmation. The platform only handles comms, not the template — no platform legal liability. (Pitched as a value prop for photographers.)

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 →