Channels and a BFF
Expo clients call JSON over HTTPS. They do not query Postgres.
Experimental AI Projects
Back in the Day
A trivia product built around place and era, not generic quiz-show facts. Players prove they remember life where they lived, when they lived there—then a Then/Now reveal shows how that place compares today.
Mobile · Prototype in Play
Local Memory, Not Generic Trivia.
Challenges are scoped to residences, schools, streets, prices, jobs, and culture for a real locale and decade. Launch geography is narrow on purpose: DFW Mid-Cities / Dallas and the Coastal Bend (Corpus Christi and Portland, Texas), so the content can be sourced instead of hallucinated.
What Ships Today
- Expo 57 client — Profile, Play, and Multiplayer on Android sideload / Expo Go, aimed at App Store and Google Play.
- Play loop — lock an answer, then a sourced Then/Now card (confidence plus pack sources) instead of a bare score tick.
- Multiplayer prototype — in-memory groups with polling: async, real-time, and 1v1 practice; websockets later.
- Privacy first — birth date, residences, schools, and workplaces stay on device. The API does not collect a full life history for MVP.
- Backend — Fastify modular monolith and Postgres in Docker; a Lightsail API is already gated for prototype play.
How Content Is Built
Facts compile from an editorial vault into playable items with locator keys (city, metro, county, era). Civic indicators can be automated; local lore stays editorial. Ranked play is not allowed to invent ungrounded AI facts—source IDs are required.
A research bridge exists to ingest notes into that vault; live research bots are off until the question stems and pack draw are tighter.
Stack
React Native / Expo 57 · Fastify · Postgres · Docker Compose · AWS Lightsail · on-device SecureStore / AsyncStorage · JSON packs and a content vault pipeline
Planned Architecture
A product platform in miniature—same seams an enterprise stack uses, smaller blast radius.
BITD is not a pile of screens on a single server. The planned system is a channel layer, a BFF that owns play and content draw, a system of record, a privacy boundary at the device, and an editorial compile path with source IDs. That is the same shape as a modern enterprise design: channels do not talk to the database; domains sit behind an API; PII is minimized; content and play are governed pipelines. At this scale those domains ship as a modular monolith so one person can operate them. The seams are there so they can peel into services when load or team size demands it—not as theater on day one.
Enterprise parallel
The names change at company scale. The responsibilities do not. BITD is the same pattern as a channel-and-BFF platform with bounded contexts, a governed content pipeline, and a hard privacy edge—shipped as one process until splitting it earns its keep.
Bounded contexts, one deployable
Auth, play, content draw, and multiplayer are modules with seams—not a single “game.ts” blob.
Privacy at the edge
Birth date, residences, schools, and workplaces stay on-device. The API never collects a full life history for MVP.
Governed content pipeline
Editorial vault → compile with source IDs → packs. Ranked play cannot invent ungrounded facts.
Realtime as a later seam
Groups are in-memory with HTTP polling. Websockets and a durable match store come when the prototype is done proving the rules.
Runtime that can lift
Docker Compose locally; Lightsail for prototype play; App Runner / ECS when ops need it.
Why It Belongs Here
BITD is product work end to end: domain design, mobile client, API, privacy rules, content pipeline, and a first cloud host. It is also the kind of AI-adjacent system I actually build— models and research help the editorial loop; they do not replace sourced questions in play.