Junto App
Role: I founded Junto and built it solo, owning the product from the first spec to a live App Store release. That meant the roadmap, prioritization, the multi-sided model, and go-to-market, not just the screens. Type: a cross-platform consumer app plus a B2B marketplace for venues and brands. Stack: React Native (Expo), React, Vite, TypeScript, Tailwind, Supabase, Stripe, and Google Maps.
Junto is a sports watch-party platform. Fans get a map-first way to find where their team's match is being shown near them. The harder bet sits underneath that: connect three sides at once (fans, venues, and brands) so the map has a reason to stay full and a way to pay for itself.
The decision that shaped everything was treating discovery as a supply problem, not a design problem. A watch-party map is only worth opening if it is already full the first time you open it. So I built the product and the content engine that feeds it as one thing, instead of shipping an empty map and hoping users would fill it.
What I shipped
Shipped a working discovery product across iOS and web, live on the App Store (v1.1.3). A real product in people’s hands, not a prototype.
Solved the cold start. Curated watch parties across 30+ metros and 140+ venues meant the map had nationwide value the first time anyone opened it.
Kept the map full without hiring anyone. An automated content engine sustains watch parties across an entire tournament with no manual upkeep.
Made expansion a data decision, not a guess. First-party analytics and a geographic heat map turn “where do we go next?” into something I can answer with evidence.
Stood up production-grade foundations alone: row-level security on every table, multi-role access, Google and Apple sign-in, and live Stripe billing.
Held one consistent experience across two platforms and four roles, down to a shared token layer.
The scope, in numbers
A quick note on what these count: they measure what I built and how much ground it covers, not how many people have used it yet. Read them as the size of the solo build, not as demand results.
2 platforms shipped (native iOS and web)
3 user personas (fan, venue, brand) plus admin
30+ U.S. metros with curated coverage
140+ curated, geocoded venues
6-hour automated content-refresh cadence, zero manual upkeep
3 venue subscription tiers
Live on the App Store (v1.1.3)
What I haven’t proven yet, and how I’d prove it
I’ll be straight about the gap: these are supply and scope numbers, not proof of demand. That’s deliberate. I proved the build and the cold-start engine first, because a watch-party map that opens empty is dead on arrival no matter how many people you send to it. The next step is putting it in front of enough fans and venues to prove demand, and here is exactly what I’d instrument: signups, activation (a fan who created or joined a watch party), and venue conversion into the paid tiers. Sequencing it this way, get the map worth opening first, then run a real demand test against it, is the founding-PM call I’d make again and defend.
The open question is demand, not the build: the next step is to instrument signups, activation, and venue conversion once real fans and venues are on it.
See it in action
The problem
I started from the job fans were actually trying to do: watch this match, out of the house, with other fans. Mapping that flow surfaced three friction points, all of them about discovery.
No way to find the crowd. Fans couldn’t see where other people were watching a specific match.
Venues without context. Listings showed bars but never tied them to a game, a team, or a kickoff time.
An empty map is a dead product. Discovery is worthless when it’s sparse, so density wasn’t a feature to add later. It was the whole bet.
Seen from the other two sides, the same gap was a distribution problem.
Empty seats, no channel. Venues host watch parties but have no targeted way to reach the fans who’d show up.
Brands can’t go local. Brands want activations at venues but had no structured way to run one.
Supply and demand never meet. Fans looking for a place, venues with capacity, and brands with budget had no shared space.
What I owned
I was the only person on the project, so every call was mine to make and defend.
Product and roadmap: what to build, what to cut, the map-first discovery model, the multi-persona information architecture, and all the microcopy.
The cross-platform build: a React Native (Expo) iOS app and a React/Vite web app on one shared Supabase backend.
The content engine: the games, venue, and event data model, the curated watch-party pipeline, and the automation that keeps it running.
The marketplace and monetization: the venue and brand surfaces, the activation workflow, and Stripe billing across three tiers.
The data layer: first-party analytics and an owner dashboard with a geographic engagement heat map.
1. Modeling the data before the UI
The map is only as good as the data behind it, so I modeled the relationships first and let the interface follow. Three objects carry the whole product.
Games come from a live sports schedule and resolve to team flags and logos, so a card reads at a glance.
Venues carry geocoded coordinates, so every watch party lands in the right place on the map.
Watch parties are the join: a specific venue showing a specific game at a specific time.
The decision I’m proudest of here is a trust one. Not every watch party is equal, so I split events into user-organized and platform-curated, and gave curated ones honest microcopy (“Heads up, Junto isn’t the organizer”) so a fan is never misled about who’s actually running the event.
2. The watch map
The product had one question to answer fast: where can I watch this, near me, with my teams? Every choice on the map served that question, and I cut anything that didn’t.
An Airbnb-style two-view experience: a scrollable list by default and a full-screen map on demand, connected by a draggable bottom sheet with three snap heights.
Always-visible pill markers and a pin-tap card carousel for fast scanning.
A team-filter strip so a fan can collapse the whole map to just their teams in one tap.
A responsive split on web that collapses to the app’s full-screen map on mobile, so the same mental model works everywhere.
The hard part was holding one experience across two completely different map stacks: react-native-maps on iOS and the Google Maps JS API on web. Making them feel like the same product is where being both the designer and the engineer paid off.
3. The curated content engine
This is the part that makes the whole thing work. An empty map kills the product, so before worrying about growth I built a pipeline that keeps the map full of credible watch parties from day one.
Verified curation: real, currently-operating sports bars across 30+ metros and 140+ venues, anchored to actual scheduled matches.
A distinct content class so curated events feel populated without misrepresenting who’s hosting.
The engine runs itself. A scheduled database job scans the upcoming schedule every few hours, generates watch parties across the curated roster idempotently and inside a rolling window, and refreshes as the tournament bracket resolves. No manual upkeep, which is the only way one person keeps a nationwide map alive.
4. The multi-sided platform
Fans, venues, and brands want very different things, so I built one product with three role-aware experiences plus an admin surface, not three apps I’d never have time to maintain.
Venues get a dashboard to publish events and reach local fans, with cleanly gated subscription tiers.
Brands run activations through venues via a structured workflow with deliverables, task tracking, and a messaging thread.
Fans stay in a focused, social experience, never burdened by operator complexity.
5. Staying consistent across four surfaces
Building solo, I needed changes to land everywhere at once and every surface to feel like one product, so I invested early in shared foundations instead of reinventing each screen.
Reusable primitives shared across the consumer, venue, brand, and admin surfaces, so a fix in one place shows up in all of them.
One token layer (color, type, spacing) expressed in both the React Native app and the Tailwind web app.
Accessibility built in from the start: WCAG contrast, larger touch targets, and dark mode.
6. Instrumenting for the next decision
A product I can’t measure is a product I’m guessing about, so I built the analytics in rather than bolting them on. The point was to make growth and expansion answerable with data.
First-party event tracking written to a privacy-scoped table.
An admin-only dashboard for logins, engagement, and a top-watch-parties leaderboard.
A geographic heat map that turns “where should we expand next?” into a data-driven answer.
What building it taught me
The most useful thing I learned was how to sequence a three-sided product on my own. Fans only stay if the map is full, venues only pay if fans show up, and brands only care if venues are active. So I built the fan side and the content engine first so the map would be worth opening, kept the venue and brand tooling ready behind them, and instrumented everything so real usage can tell me where to invest next. The analytics are in place and the next move is honest: put it in front of real fans and venues and read the numbers on signups, activation, and venue conversion. That order (make the map worth opening, then prove demand, then turn on monetization) is the call I’d bring to any early-stage product team.
The lesson was sequencing a three-sided marketplace solo: make the map worth opening first, then prove demand, then turn on monetization.
Tech and architecture
Mobile: React Native (Expo Router), TypeScript, react-native-maps, @gorhom/bottom-sheet, Zustand.
Web: React 18, Vite, Tailwind and shadcn/ui, wouter, Google Maps JS with custom overlay markers and a heat map.
Backend: Supabase with PostgreSQL and row-level security, Edge Functions, pg_cron for automated content, and Storage.
Payments: Stripe, consumer-free plus three tiered venue subscriptions.
Auth and security: Supabase Auth (Google and Apple OAuth), role-based route guards, and RLS on every table.
Junto turns watching sports alone into finding your crowd: one map, one tap, every match.
