Felt Faction iOS app v2 — replacement direction + chip-counting

Brainstormed 2026-06-16 in response to: "I want to build the iOS app as a

replacement for the website, making is more convenient for the members,

and the added ability to send push notifications to the members as

well. it will also give us the oppotunity to make the experience more

seemless. but how can we track the profits and losses for the casino

games (poker, blackjack, roulette etc) without manual entry/manual count

by connor or myself (the admins)? using a vision model to count the

chips for us—getting the user to upload there own profits or losses?

lets think deeply about this and how we can develop the best user

experience."

The pivot (verbatim from user)

"I want to build the iOS app as a replacement for the website, making

is more convenient for the members, and the added ability to send

push notifications to the members as well. it will also give us the

oppotunity to make the experience more seemless."

This is a major shift from the v1 brainstorm (sibling product). Implication: stop investing in the web app; web becomes a public/marketing surface or gets killed entirely.

The chip-counting problem — the actual answer

The constraint (re-stated correctly)

The pain is at the end of the night — counting 12 stacks. The chips are tokens tracking net change. The "P&L" question reduces to ending stack − buy-in(s), not 12 separate transactions.

Three approaches, ranked

A. Buy-in self-report + photo of ending stack (RECOMMENDED for v1)

• Member self-reports buy-ins: "I bought in for $X" / "Rebought $Y at break"
• Photo of ending stack at cashout
• Vision counts chips → final stack value
• P&L = final − buy-ins
• 12 photos at end of night, processed in parallel
• Server-side vision (Claude Sonnet / GPT-4V) for v1
• Pros: minimal friction, low compute, "ritual" feel
• Cons: requires standardized chip set, consistent lighting

B. Photo of starting + ending stack (more rigorous, more friction)

• 24 photos per session, 2 photo moments per player
• Pros: no buy-in self-report
• Cons: 2× the friction, requires remembering to photograph at buy-in

C. Self-report only (the fallback)

• "I won $X" / "I lost $Y" button
• Pros: zero compute
• Cons: humans lie, get drunk, round, forget — exactly what user is

trying to avoid

Recommendation: A for v1, with C as the fallback for low-confidence

vision results.

The killer move: vision is the audit layer, self-attest is the trigger

• Vision computes P&L automatically (the primary)
• Player self-attests: "Looks right" or "Off by $X" (the fast path)
• If self-report disagrees with vision → flag for Connor to review
• If player doesn't self-attest within 24h → vision value is canonical
• This catches the "I was drunk and forgot" case without burdening the

sober players

The end-of-night UX

For the member (3 actions, ~30 seconds):

1. Buy-in: tap "I bought in for $X" at the start. One button.
2. Play: chips move around, no app interaction
3. Cashout: tap "Cash out" → camera opens → hold over stack → 2 sec

→ "Your P&L: +$X. Confirm?"

1. (Optional) "Adjust" if the number is off

For Connor (3 actions, ~2 minutes):

1. "Start session" — opens the buy-in window
2. Members self-buy-in during the session
3. "End session" — confirms all stacks are settled
4. Review any disputes, hit "Finalize"
5. Vault recap auto-generated

The technical layer

v1: Server-side vision API

• Photos uploaded to Supabase storage
• Claude Sonnet Vision or GPT-4V counts chips (one-shot prompt with

reference colors)

• P&L computed, returned to client
• Cost: ~$0.01–0.03 per photo. For 12 members × 1 photo = $0.12–0.36

per session. Trivial.

• Latency: 2–5 sec per photo. Fine.
• Pros: zero model training, leverages SOTA vision
• Cons: requires network at end of night (usually fine in a house),

privacy (sending chip photos to server)

v2: On-device Core ML model

• Custom model trained on the Felt Faction's specific chip set
• Photos never leave the device
• Latency: <1 sec
• Pros: offline, private, free at inference
• Cons: requires training data (~500 labeled photos), 1–2 weeks of work
• Build path: start with server-side in v1, collect data, train Core

ML for v2

Hybrid: on-device first pass, server fallback on low confidence

• iOS Vision framework does quick first pass
• If confidence < 0.85, upload to server for second opinion
• Best of both worlds, more complex
• Probably not worth it for v1; revisit in v3

The chip-counting sub-problems (technical detail)

1. Detection — locate each chip. Easy with modern vision.
2. Classification — what denomination. HARD if chip set varies,

EASY if standardized.

1. Counting — how many of each. Hard when stacked (only top

visible), easy when fanned.

1. Occlusion — chips behind chips. Mitigated by "fan out for the

photo" or side-of-stack photo.

Mitigations baked into the UX:

• Prompt: "Fan your chips for the photo" (a 1-second action)
• Alternative: side-of-stack photo (chip colors visible as stripes)
• Reference object: a playing card next to the stack for scale
• Standardized chip set: 5 colors, 5 denominations, registered once

in the app (one-time setup with reference photos)

Social games (Phase II) — no chip problem

These don't have chips. They're tracked as "Social Dividends" — manual entries. Not a vision problem. Maybe a "+1 to Olivia for the burn" button.

Push notifications (the full lifecycle)

Now possible because iOS:

• Pre-session (48h): "The Briefing — Saturday 7pm. 9/12 confirmed.

Claim Your Seat."

• Session start: "Session starting now. Buy in?"
• During session: rare, silent. "Olivia just overtook you — Position

at Risk."

• Cashout: "Photo your stack. Settling in 3...2...1..."
• Post-session: "Settled. +$X. New standing: #4. Vault is ready."
• Streak: "3 sessions in a row. Don't break it."
• No-show tax (the actual enforcement): "You didn't show. −200 CC

applied. Next session?"

• Season finale: "Season finale in 1 week. You're #3. Top 3 =

invitation."

The no-show tax becomes enforced not stated. That's a big change — the rule is no longer "Connor will remember to deduct it."

Website replacement — the actual decision

If iOS replaces the web, what happens to the web app?

Option A: Web becomes public/marketing only

• Keep the public briefing, the public ledger (anonymized), the

marketing pages

• Members only use iOS for everything else
• Lower maintenance burden
• Web stays as a recruiting surface

Option B: Kill the web entirely

• Marketing moves to Notion / Carrd
• Members only have the iOS app
• Maximum control, minimum maintenance
• "By invitation only, app required" — strong brand signal

Option C: Web stays as the Pit Boss admin surface (RECOMMENDED)

• Connor and Nathan use the web for admin: settle, registry, season

management, big-picture analytics

• Members only use the iOS app
• Split: iOS for the experience, web for the operations
• As iOS gets more admin features, the web can be killed later

What "seamless" actually means (5 seams)

The user said "make the experience more seemless." Let me unpack:

1. Seamless between the room and the app: Live Activities during

sessions, Haptics for "your turn," Watch for glances.

1. Seamless between members: iMessage extension, Share Sheet,

Spotlight.

1. Seamless between sessions: The Vault recap is automatically

generated and shared. The Briefing appears 48h before the next session. The season finale is calendared.

1. Seamless between the app and the room: Vision does the counting

so the app is invisible at the table. Push notifications bring the room to you when you're not there.

1. Seamless between physical and digital: The chip photo IS the

ledger entry. No "I'll log it later." The act of taking the photo is the act of settling.

The last one is the deepest. The act of cashing out is taking the photo of your stack. They're not separate steps. The photo is the receipt. The P&L is computed at the moment of cashout. The session is settled at the moment the last stack is photographed. There's no "log it tomorrow."

The phone is just the ledger's witness. It's not an interruption; it's a ritual.

Updated v1 cut (was 5 features, now 9)

Carried from v1:

1. Glance (Widget + Live Activity + Watch complication)
2. Claim Your Seat from Lock Screen
3. Apple Watch app (1-screen "Tonight")
4. Quick Settle (Face ID, Taptic, big numbers)
5. Native push for Briefing

New from v2:

1. Buy-in flow — single button at session start
2. Cashout with chip photo — camera → vision → P&L → confirm
3. Self-attest / audit — the hybrid layer
4. Push notifications — full session lifecycle

~10-week scope. Still doable. The chip-photo flow is the biggest new surface — recommend a 1-week spike first to validate the server-side vision approach with a hand-rolled PoC.

Open questions (deeper than v1)

1. Server-side vs on-device vision in v1? Server is faster to

ship. On-device is more private. Default: server for v1, on-device for v2.

1. Dispute resolution — if self-report and vision disagree, who's

the tiebreaker? (Connor, the Pit Boss.) What's the UX for that?

1. Multi-table nights — if 6 are at poker and 6 are at social, do

we need separate cashout flows? (Poker yes, social no.)

1. Buy-in reboughts — track multiple buy-ins, or just total? Total

is simpler; track the count for transparency.

1. Buy-in source of truth — cash, Venmo, CC? Felt Faction is

CC-internal; buy-ins are in real money. The P&L is in CC. The buy-in $ → CC conversion needs a defined rate.

1. No-show tax — auto-debit the ledger on push notification, or

wait for Connor to confirm? Auto-debit is the right move; let Connor dispute.

1. Privacy of chip photos — sensitive ("this person won/lost

this much"). Cloud storage, deletion policy, access control. Suggest: auto-delete after season end + 30 days, only Connor/Nathan can view.

1. The chip set itself — what denominations, what colors? If

Felt Faction standardizes, vision is much easier. If they don't, the app needs a "register your chip set" flow (one-time setup with 5 reference photos).

1. What about the "social dividends" tracking? No vision problem

here. Manual entry. Could gamify with quick "Award a Dividend to..." buttons.

1. The 2-second vision latency — is that OK at the table? Or

does the UX need to feel instant? Suggest: show a "Scanning..." indicator for the 2 sec, then animate the result. The 2 sec is itself part of the ritual.

The first move (concrete recommendation)

Don't build the iOS app yet. Build a 1-week spike first.

Take 50 photos of poker chip stacks (different denominations, different lighting, different sizes) and feed them to Claude Sonnet Vision with a one-shot prompt. Measure:

• Accuracy of total value
• Latency
• Failure modes
• Worst case

This validates the technical approach before investing in iOS infrastructure. If the vision works, ship v1 with server-side. If it doesn't, fall back to "self-report only with photo evidence for disputes" and rethink.

This is the cheapest way to de-risk the biggest unknown in the project.

Connection to Hydrolyze

The Hydrolyze patterns that map:

• Supabase client setup, anon-key + JWT in Keychain
• SwiftUI dark mode discipline
• Haptic feedback
• WidgetKit

Hydrolyze doesn't have:

• Computer vision workflows (new territory)
• Live Activities
• Group/season context

The vision workflow is new. Worth its own spike (separate from the app, separate from the data model — just a script + 50 photos + a spreadsheet of results).

The line to walk (refined for v2)

The v1 framing: "Felt Faction is the most fun thing you do with your phone, and it's with these specific people."

The v2 framing: "Felt Faction is the most fun thing you do with your phone, and the night is settled before you leave the table."

The new key insight: the act of playing the game IS the act of using the app. No separation. The phone is just the ledger's witness. It's not an interruption; it's a ritual.

See also

• Felt Faction iOS app — brainstorm — v1 direction (sibling

to web, not replacement). Superseded by this page for product strategy; the technical primitives (Glance, Live Activity, Haptics) are still valid.

• Felt Faction — project hub

Takes

<!--- gbrain:takes:begin --> | # | claim | kind | who | weight | since | source | |---|-------|------|-----|--------|-------|--------| | 1 | Stop developing the web app for members; retain web for public recruiting and admin operations until iOS can absorb the admin features. | take | brain | 0.85 | 2026-07-19 | propose_takes#1096 | <!--- gbrain:takes:end -->

Published and managed by TARS, an AI co-author built on Nathan's gbrain.