Expo across web and mobile
Expo, React Native, and React Native Web carry one product vocabulary across web, iOS, and Android targets while preserving format-specific behavior.
Back to selected work
Case study | Expo + React Native product system
Poolhouse
A cross-platform Expo and React Native product for web and mobile, backed by Supabase/PostgreSQL workflows that turn six pool-format rule sets into validated picks, private-group access, automated scoring, and recoverable standings.
- Role
- Product ownership; requirements, workflow and data design, Codex-assisted implementation, testing, and stewardship.
- Stack
- Expo, React Native, TypeScript, Supabase/PostgreSQL, Row Level Security, and Edge Functions.
- Formats
- Survivor, Wins, Squares, 10-Digit, Spread, and match-play; availability varies.
- Outcome
- Validated private-group workflows, automated score synchronization, and explicit current, saved, pending, unavailable, and recovery states.
Evidence snapshot
A polished cross-platform interface backed by testable rules and data.
The mobile screenshot shows pick entry, but the stronger proof is the product system around format-specific data, client and database authority, authenticated private access, automated score refresh, and standings recovery.
- Public product surface Expo, React Native, and React Native Web support pool details, pick entry, and standings-oriented flows across six format categories whose availability varies.
- Requirements-to-data boundary Product rules become structured data, client validation, typed database operations, and independent backend rechecks.
- Pre-submit boundary Schedule-aware client checks catch missing, eliminated, locked, off-schedule, opposing, reused, and duplicate choices.
- Authentication and authorization Supabase Auth, private-group membership, commissioner permissions, and Row Level Security keep access decisions close to the underlying data.
- Deadline claim boundary Closed-window state appears before submission. Backend authority is not presented as a universal server-side kickoff comparison.
- Recovery and privacy Transient refresh failure can preserve labeled saved results, but authorization loss clears retained private rows and blocks their display.
Refresh result + current viewing authority
- No saved snapshot + refresh failure
- Unavailable
- Current results + unchanged response
- Current
- Current results + transient failure
- Labeled saved results
- Saved or unavailable + retry success
- Current
- Current or saved + authorization loss
- Access blocked; retained rows cleared
Problem
Sports pools need clarity, speed, and trust.
Pool apps combine format rules, lock windows, changing scores, private groups, and user trust. Poolhouse keeps pick entry legible while its cross-platform system separates client guidance, backend rule authority, automated score synchronization, recoverable standings, and access control.
Product ownership
Turn product rules into a usable, maintainable system.
The work starts with the decisions and behaviors users need: create a private group, enter valid picks, understand lock state, and trust the standings. Those requirements become data structures, product workflows, validation boundaries, database operations, authorization controls, and explicit failure and recovery states.
Directed Codex-assisted SQL and application development for a Supabase/PostgreSQL backend, translating product requirements into data structures, validation rules, access controls, automated score workflows, and tested recovery states.
Unit, database-security, Edge Function, browser, accessibility, performance, and release checks support troubleshooting, deployment, and continued product stewardship across the web/mobile system.
System
One cross-platform application, from product rule to database operation.
Rules become data workflows
Pool formats, rounds, matchups, entries, selections, and scoring state are modeled for typed Supabase/PostgreSQL operations, client validation, and backend rechecks.
Private access stays authoritative
Authentication, private-group membership, commissioner permissions, and Row Level Security govern who can view or change protected pool data.
Score synchronization exposes state
Protected Edge Function workflows coordinate automated score synchronization and distinguish current, saved, pending, unavailable, retry, and access-revoked states.
Decisions
Make a rules-heavy product feel simple without hiding the rules.
Client guidance is not database authority
Client validation explains missing, ineligible, opposing, reused, or duplicate choices. Authenticated database operations independently recheck membership, ownership, and core rules before an atomic write. A closed-window state remains a client boundary, not a universal server-side kickoff guarantee.
Saved results beat an unexplained blank
An unchanged response can preserve current results, while transient failure can retain a visibly labeled last-known-good snapshot.
Authorization outranks availability
Access loss clears retained private rows and caches instead of allowing saved standings to outlive viewing authority.
Protected detail
Public proof excludes repository details, invite codes, member data, operational logs, and account-specific configuration.
Outcome
A polished app surface backed by real product logic.
Built, tested, deployed, and continued to steward the web/mobile product through repeatable release and recovery gates. Poolhouse demonstrates product ownership beyond a framework list: product requirements become structured data, usable workflows, validated outputs, explicit edge and failure states, protected database operations, and a system that can be explained and maintained.