Building HeatSync Part 2: Defining the MVP
In Part 1, I shared how a forgotten heat sheet at a swim meet led me to discover that ChatGPT could extract my kid’s events and create calendar reminders. That one-off hack worked, but wasn’t something I could share with other swim parents. So I decided to build a proper tool.
The Core Problem
Before writing any code, I forced myself to define the problem clearly.
Swim parents need to track their kids’ event times during meets, but traditional methods (print, highlight, carry) are error-prone and easy to forget.
Simple. Clear. Not “revolutionize swim meet management” or “build a platform for competitive swimming.” Just: help parents not miss their kid’s race.
Who’s Using This?
I identified three user types:
- Swim parents (this is me) checking their kid’s race times on their phone at the meet
- Swimmers who are old enough to manage their own schedule
- Coaches/team managers who might share extracted results with the whole team
For MVP, I focused on #1. If it works for parents, the other use cases follow naturally.
The Scenario That Matters
I kept coming back to one specific scenario: parent at the pool, phone in hand, meet about to start.
This meant:
- Mobile-first: not just “responsive,” but actually usable on a phone
- Fast: nobody wants to wait 60 seconds staring at a loading spinner
- Simple: no account creation, no onboarding flow, no cognitive load
MVP Scope
Here’s what I committed to building:
| Feature | Why |
|---|---|
| Upload PDF or paste URL | URL is more convenient (heat sheets are always on meet websites) |
| Enter swimmer name | AI extracts only that swimmer’s events |
| One-click .ics export | Universal format, works with any calendar app |
| Mobile responsive | The at-the-meet scenario |
And here’s what I explicitly cut:
| Rejected Feature | Why Not |
|---|---|
| User accounts | Adds friction, not needed for core flow |
| Google Calendar direct integration | OAuth complexity, .ics works fine |
| Multi-swimmer support | Nice to have, but one swimmer at a time is enough for MVP |
| Push notifications | Complex, requires PWA infrastructure |
Cutting features is hard. Every feature you add is a feature you have to build, test, and maintain. For a side project, ruthless scoping is your friend.
OKRs
I borrowed the OKR framework to set measurable goals:
Objective: Help swim parents never miss their kid’s events
| Key Result | Target |
|---|---|
| PDF upload to calendar export | under 30 seconds |
| Extraction accuracy | over 95% |
| Mobile usability | Fully functional on phone |
These aren’t vanity metrics. Each one maps to a real user need:
- Under 30 seconds: respects the user’s time (and their patience at a busy meet)
- Over 95% accuracy: missing an event defeats the entire purpose
- Mobile: where the tool will actually be used
The Anti-Pattern I Avoided
I’ve seen too many side projects die from scope creep. You start with “a simple tool” and end up with a backlog of 47 features, none of them finished.
My rule: ship the smallest thing that solves the problem, then iterate.
HeatSync v1 does exactly one thing. It does it well. Everything else can wait.
This is Part 2 of a series on building HeatSync. ← Part 1: The Origin Story | Part 3: Making It Work →