CASE STUDY · SPOTIP

Spotip.

A real-time football experience, engineered from the ground up.

ROLELead Mobile & Product Engineer
SCOPEEnd-to-End Product Ownership
SCALE3,000+ Fixtures Concurrently
OUTCOMESub-3s Targeted Updates

1. Project Context & Product Breadth

Spotip was conceived as a high-density, real-time football companion app designed to bring live match scores, statistical predictions, detailed lineups, and social contest leagues into a single fast mobile client.

I built Spotip from its earliest prototypes and later led its full product engineering. The application needed to handle continuous streams of incoming match updates across hundreds of active leagues worldwide, without lagging, dropping frames, or misrepresenting game states.

2. The Engineering Problem

Real-time sports applications encounter an acute state synchronization challenge: at peak weekend match times, thousands of matches are in progress simultaneously. Events arrive asynchronously—goals, penalties, yellow cards, substitutions, and second-by-second clock ticks.

In standard mobile list architectures, dispatching global state updates triggers top-to-bottom re-renders across the entire fixture hierarchy. For a screen rendering 50 to 100 visible matches across multiple competition headers, re-evaluating the full virtualized tree caused immediate scroll jank, visual stutter, and excessive battery consumption.

3. Role & Responsibilities

As lead engineer owning the product, I was responsible for:

  • Architecting the mobile client and state subscription topology.
  • Designing granular data normalizers to decouple tournament groupings from fixture updates.
  • Implementing the custom fixture list virtualization and diffing engine.
  • Collaborating on backend payload compression and delta-update specifications.

4. Architectural Decisions & Tradeoffs

DECISION 01

Selective Fixture-Level Subscriptions

Rather than subscribing the entire matches view to a monolithic store, each fixture row subscribes exclusively to its own unique match ID channel. When Benfica scores against Monaco, only that specific row component executes an update. Neighboring rows remain completely idle.

DECISION 02

Separation of Live vs. Completed States

Completed fixtures (FT) transition into an immutable frozen state cache. This eliminates polling or reactive listeners for finished matches, drastically reducing runtime memory pressure and CPU wakeups during long sessions.

6. Measurable Outcomes & Evidence

The selective update architecture achieved:

  • 3,000+ fixtures managed concurrently without degraded responsiveness.
  • Sub-3s updates from event ingestion to mobile UI update.
  • Consistent 60 fps scrolling performance during dense peak match hours.
  • Full product ownership through conception, iterative shipping, and scaling.

What are you working on?

I’d love to hear about it.