QuickMeet is a venue-anchored social discovery tool. A QR code on a bar coaster opens a mobile web experience — no app download required. Users register with a phone number, build a minimal profile, set a visibility status, and can see who else is checked in at the same location right now. The core design principle is that the app facilitates in-person connection; it does not replace it. Matching, pinging, and contact exchange are nudges toward a conversation, not a substitute for one.

Three personas in v0.2. End-user sub-segments (bachelor / friend group / solo traveler / networker / regular / curious lurker) are detailed in the Business Growth Model doc.

11 nodes in v0.2. Two new steps from the v3 baseline: Invite your group after profile, and a richer Post-session step at the end. Affiliate-attributed scans branch into the QR resolution and feed downstream attribution.

Three layers: client (mobile PWA + admin web), backend services, and data. The physical QR code is the only entry point — it encodes a URL that pre-loads venue context, eliminating any manual location selection.

The QR code encodes a URL like quickmeet.app/join?code=abc123. The code token maps to a QR_CODES record. Redis stores real-time presence per venue as a sorted set. PostgreSQL is the source of truth; Redis is the fast read layer for "who is currently here."

12 entities in v0.2. Three new in v0.2: AFFILIATES, AFFILIATE_CODES, and EVENTS. QR_CODES and CHECK_INS gain optional affiliate_code_id and event_id for attribution.

Key design decisions: phone number is the durable identity anchor — a USERS record persists forever across sessions. CHECK_INS has a visibility_mode field (per-session, not per-user). PINGS are directional with a status lifecycle. CONTACT_BUMPS requires both parties to act within a time window. USERS now also carries a subscription_tier for the freemium model.

v0.1 introduced visibility_mode on CHECK_INS and the optional profile-completion fields. v0.2 adds three new entities (AFFILIATES, AFFILIATE_CODES, EVENTS) and extends QR_CODES, CHECK_INS, USERS, and VENUES for the freemium and affiliate models.

Trust is the product. A nightlife social product collapses fast if users feel unsafe or surveilled. v0.2 codifies the safety, identity, and data-handling guardrails — many were implicit in v0.1.

Six logical tiers: client surfaces (patron PWA · admin · affiliate console), edge / DNS, auth, API (sync + real-time), data (Postgres · Redis · S3), and async / events. Solid arrows are request/response; dashed arrows are notifications, events, or telemetry.

Color key: stores (Postgres + S3, system of record) · cache (Redis: presence, sessions, pub/sub) · compute / messaging (Lambda · API GW · AppSync · pgmq · SNS · Rekognition) · edge / identity (Route 53 · CloudFront · Cognito) · ops (CloudWatch · Secrets · WAF).

Every check-in is dual-written: a durable row in Postgres, plus a hot record in the Redis sorted set venue:{id}:live. "Who's here now" reads only Redis; Postgres is the rebuild source.

The three-stage social mechanic. Match is detected atomically when a mutual ping exists; canonical ordering (user_a_id < user_b_id) prevents duplicate matches. Bump requires both users to set a Redis SETEX key within a 30-second window — when both keys exist, contact info is exchanged.

Identity is unified — there is no separate affiliates table. The affiliate is just a USERS row with an optional 1:1 AFFILIATE_PROFILES extension. Every user has an informal profile by default (so anyone can carry a personal referral QR); filling in payout details and being approved promotes them to formal status, which unlocks monthly disbursement.

Pilot ~$32/mo · Growth ~$791/mo · Scale ~$3,674/mo. Cognito dominates above 50k MAU — migration trigger set at 25k MAU or $300/mo Cognito bill. Lambda stays cheap across all three tiers; pgmq on the existing RDS instance avoids the SQS line entirely at pilot.

Full line-item cost model: architecture/QuickMeet-Architecture.md §6.

Sixteen tables. Unified identity: the standalone affiliates table is gone — affiliate_profiles is a 1:1 optional extension on users, so any user can carry a personal referral QR without holding a second account. A trigger creates an informal profile for every new user. qr_codes is unified with a type discriminator and nullable affiliate_user_id / event_id FKs. check_ins.current_zone stores the venue zone hint surfaced on a match. revenue_events is the placeholder ledger for the admin revenue dashboard. Live presence reads from Redis sorted sets, not Postgres.

Notable design decisions: qr_codes uses a CHECK constraint enforcing that affiliate QRs reference an affiliate user and event QRs reference an event. matches uses canonical ordering (user_a_id < user_b_id) to prevent duplicate match rows. admin_venues is M:M (regional admin covers multiple venues; venue can have multiple admin contacts) — wider than the v0.2 spec's 1:M.