Yahoo Daily Fantasy — Android Launch & Scale

The Challenge

Yahoo needed to launch a daily fantasy sports product for the Android market in a compressed 12-week window — tied to the start of an NFL season. Miss the date, and the product loses its market moment.

The constraints were aggressive:

• 12-week deadline — hard, tied to NFL season opener
• Real-time data requirements — live scores, player stats, contest standings updating every few seconds
• Financial transactions — entry fees and payouts requiring PCI compliance considerations
• Scalability concerns — expecting spike traffic at game kickoff times

Approach

I joined as the lead Android developer on a team of three, responsible for architecture decisions, real-time data layer, and final quality assurance.

Architecture for Speed + Reliability

Given the timeline, the architecture needed to be:

1. Predictable — junior developers could work in parallel without stepping on each other
2. Testable — no time for manual QA of every edge case; unit tests had to catch regressions
3. Real-time capable — WebSocket integration without blocking the UI thread

Chose MVVM with a unidirectional data flow (early MVI-adjacent pattern using sealed classes for state). This made the real-time state management straightforward: a single ContestState sealed class that the UI simply renders.

Real-time Data Layer

The core technical challenge was managing live contest data efficiently:

• WebSocket connection managed by a ContestRepository that reconnects gracefully on network drops
• StateFlow broadcasting updates to all ViewModels that care — no polling, no race conditions
• Optimistic UI updates for lineup changes with rollback on server rejection
• Background sync continues when the app is backgrounded (within Android’s battery restrictions)

Transaction Flow

For entry fee collection and payout display:

• Integrated Yahoo’s internal payments SDK with a clean abstraction layer
• All financial data flows through a single WalletRepository — no direct API calls from ViewModels
• Added offline-aware error states (no connectivity → clear message, no silent failure)

12-Week Execution

Weekly milestones with explicit go/no-go gates:

• Weeks 1–3: Core screens (lobby, contest detail, lineup builder) — skeleton navigation
• Weeks 4–6: Real-time data layer, WebSocket integration, live scoring
• Weeks 7–9: Transaction flow, wallet integration, entry/withdrawal
• Weeks 10–11: Performance pass, crash rate reduction, Play Store prep
• Week 12: Beta, fix, release

Results

Metric	Target	Actual
Launch date	NFL Week 1 opener	✅ On time
Downloads (30 days)	200K	500K+
Play Store rating	4.0★	4.5★
Launch day crash rate	<1%	0.4%
P95 screen load time	<2s	1.4s

The app processed over $2M in entry fees on launch day without a single transaction-related incident. The WebSocket layer handled the concurrent connection spike at game kickoff (est. ~80K simultaneous users) without degradation.

Key Lessons

Scope ruthlessly. The initial spec included social features (league chat, player comparisons). Cut both in week 2 — they weren’t core to the value proposition and would have jeopardised the date. Shipped them in v1.1 three weeks later with proper time to do them well.

Real-time ≠ complexity. The WebSocket layer looks simple in hindsight. That simplicity was the result of three architecture sessions in week 1 where we killed every clever idea and asked “what’s the dumbest version of this that works?” The dumb version handled launch day fine.

Test the happy path and the network drop. Most of the QA time went into network failure scenarios — no connectivity, slow 3G, mid-transaction drops. These are the scenarios that earn 1-star reviews if you ship them broken.