Case study
MapChat: a consumer social app from a founding team with no engineering staff
The starting point
MapChat is built on a specific read of the loneliness problem: people want real-life connection and will show up for it, but only when it feels low-pressure. The app routes that through local venues: see what's happening nearby, see who's going, check in, wave, play. When I joined in July 2025 the founding team had that thesis, early designs, a Bubble.io prototype, and no engineers. The prototype was already failing: a web app on Bubble.io where records stored as parallel arrays corrupted under concurrent writes, chat polled every 3 seconds, and there was no row-level access control and no version control. Small changes took days to verify by hand.
I own product direction, architecture, design direction, and the entire build.
The build model
The rebuild moved MapChat to React Native and Expo, built entirely through agentic development. AI agents write every line of production code; I write the specs, the architecture, and the review gates they work under, and nothing merges without passing 12 automated gates plus my approval. Agentic coding multiplied delivery speed, and that made architecture the highest-stakes work: scaling decisions are the one thing I never hand to AI. That tradeoff is why the perf lab exists: a Dockerized replica of the production Supabase stack where risky database work gets measured before it ships. It has paid for itself. An EXPLAIN ANALYZE audit of every discovery RPC at production scale caught the app's heaviest query spending 4,168 ms on a query-shape bug (the same logic ran in 66 ms written literally), and a concurrency probe measured the launch-tier database's real ceiling at 30-50 concurrent users against a 1,000-user target. The roadmap moved on those numbers: the expensive count feature went behind a fail-safe flag, structural query fixes got sequenced ahead of caching, and compute sizing waits until the queries are cheap. That system is its own story: the process →. This page is about the product.
Platform decisions
Postgres over Firebase. The product needed row-level security and real geospatial queries. Supabase gave me both (RLS and PostGIS); Firebase would have meant faking relational integrity in application code. Supabase also fit the build model: the whole platform can be driven from Claude Code, so the same agentic process that writes the app operates the database. The data layer now runs 482 row-level security policies, and sensitive writes go through server-side functions only.
A phased escape from Bubble, not a rewrite-and-pray. The app kept running while the backend moved piece by piece onto versioned SQL migrations and typed edge functions. The worst offenders went first: the parallel-array records that had been corrupting data were rebuilt as proper foreign-key tables, and chat moved off its 3-second polling loop onto realtime WebSockets. PostGIS took over the geospatial work.
One full redesign, cut over in place. In July 2026 the app's visual system and information architecture were replaced on the live app: 5 tabs became 4 behind an umbrella flag, the flag flipped, then the flag and the entire legacy code path were deleted. Same store listings, no re-release, nothing for users to reinstall.
What shipped
The app ships on iOS and Android. What's live today:
- Social: profiles with an AI bio writer (generates candidates, refines on request), friend requests, waves, open parties, bulletins, and live check-in presence at venues.
- Chat: DMs, group chats, and venue rooms, with emoji reactions and "who reacted", GIF send, image messages over signed URLs, swipe-to-reply with quote jump, typing presence, and read receipts. 8 realtime channel families behind a central registry keep all of it live.
- Map and check-in: a clustered map over thousands of venues with a 50-mile query radius, and 150-meter geofenced check-ins with server-side auto-checkout.
- Games: 16 live multiplayer games played inside the app. 8 are party games, including trivia on a curated, fact-checked question bank; 8 are parlor card games (poker, blackjack, hearts) sharing one trick-taking engine. Above them sits Morpho, the meta-game that ties social, discovery, and showing up together with an in-app currency and rewards.
- Notifications: 4 channels (push, email, SMS, in-app), drained by 10 scheduled jobs with dead-letter reaping.
- A design language: an editorial newspaper aesthetic on a 189-token typed theme system, shipped across the entire app in the July cutover.
- Release machinery: 3 build profiles, 6 CI workflows, over-the-air updates restricted to CI-built JavaScript, a force-update gate, and Sentry with full tracing and PII scrubbing.
- The public face: mapchat.social, with a database-wired waitlist and first-touch attribution on store clicks.
Natural-language search is designed and scheduled for the next cycle.
Where the features came from
Behind the feature list is a research base: hundreds of conversations over 3 years with venue managers, bartenders, and the Gen Z and millennial target audience. Dozens of those conversations were mine, at venues. The low-pressure thesis came out of them, and it picked the features: the wave, the games and icebreakers, open parties, and the chat design all trace to it.
Beta groups on both platforms (20+ on TestFlight, 18 on Play internal testing) used the app before launch, and their reports turned into defect fixes. The games went through twice-weekly playtest sessions with the internal team and beta users, which decided the lineup. The next iteration is being shaped the same way: usability testing and user research are driving it, including privacy-first friend discovery now in progress.
The supply side
A venue app with no venues is dead on arrival, and there was no budget for data vendors. The answer became a second product: BarFly, an internal cataloging CRM built by another founding teammate (Flask and React on Azure, Microsoft 365 sign-in, per-field audit trails, scrape automation). I collaborated on BarFly; I don't claim it. What I owned was the seam between the two products: one Postgres serves both, catalog tables are CRM-write and app-read behind a consumer-visibility flag, Microsoft 365 identities bridge to signed database JWTs so row-level security applies per user, and a one-shot ETL moved 40,260 rows at a 100% source-to-destination match with zero foreign-key orphans.
Through that pipeline the production catalog grew from 1,925 venues to 9,491 in 2 months, driven by agent-run scraping with human review; 1,761 venues are deep-catalogued across 201 fields each. On the MapChat side I built the recurrence engine: recurring happenings are stored as recurrence rules in the same standard format calendar apps use (RFC 5545), then materialized into dated instances daily. About 14,000 templates have run with 0 failures since May 2026. The app serves 284,000+ live events and specials, the count a production audit measured in June 2026.
Launch, and a live test
Apple and Google approved the app in May 2026, and it has run in production since, with zero data-corruption incidents. In July the team ran its flagship activation, an LA-wide bar crawl. I designed the physical event and shipped the supporting in-app feature (16 stops, 20 challenges, a live leaderboard, city-wide chat, and a fraud-resistant points ledger) in 8 days. 100 people RSVP'd. 57 showed up, a 57% show rate.
The event doubled as a live study. Social discovery and the games hit hardest, Emoji Off and PairPlay especially. Check-in did not: people forgot to open the app at the venue, and those who remembered had trouble finding it. The bulletin board sat hidden inside venue pages. Both are being redesigned to be more visible in the next iteration.
Venues are in the loop too: multiple collaborations have them carrying MapChat posters and postcards in their spaces. More local crowd through the door is exactly what they want.
What didn't survive
The first event-ingestion system, a LangGraph pipeline with LangSmith evals built in March, proved the idea was feasible and then lost to a simpler architecture: catalog, recurrence templates, scraping runbooks. The evals made killing it a quick decision. 2 of the 18 games didn't survive playtesting either.