A sports management problem hiding in plain sight
In 2004, I was a freelance PHP developer running my own company, Leafbreeze Productions, when a small design firm in Portland, Oregon, Sparkplug, hired me to prototype an idea. They had a vision for a team management tool called TeamSnap. The problem? They thought team parents ran everything. My experience told me otherwise.
Coaches, not parents, needed this tool. They were the ones scrambling to keep their teams organized, juggling schedules, last-minute changes, and constant questions. If this product was going to work, it had to be built for them.
So, I challenged Sparkplug’s assumptions and reframed the entire product strategy around the people who actually managed teams. That insight changed everything.
From concept to clickable prototype
To me, building a web app always starts with paper sketches (TeamSnap v1.0). I worked closely with Sparkplug’s designers, mapping out workflows on whiteboards and butcher paper. I ran site visits and watched how coaches and parents interacted. What I saw was a mess. There were late arrivals, missed payments, and endless confusion over schedules.
Personas formed right in front of us:
Coach Bob just wanted to focus on the game, but he spent half his time answering the same questions over and over.
Parent Ann was overwhelmed, trying to fit practice schedules into an already packed life.
Parent Matt forgot anything that wasn’t written down.
It was clear. This tool wasn’t just about managing teams. It was about controlling chaos.
With a solid problem definition, I built the first working prototype (TeamSnap v2.0). It was a LAMP-stack web app (using PHP, MySQL, SMARTY, and PEAR) that brought scheduling, rosters, and payments into one place. The interface was designed for efficiency. Coaches could update schedules, notify parents, and track payments in seconds. Parents could finally stop texting coaches every five minutes.
Pivoting for the real customer
Our first round of testing revealed something surprising. Coaches needed a dashboard, but the real source of their frustration was parents. If we wanted to help coaches, we had to help parents first.
So, we pivoted.
The UI shifted to a parent-first experience. The homepage answered all the common questions upfront. A structured notification system eliminated miscommunication. This included features like Payment Tracking that removed the always awkward "Hey, you still owe team dues." conversations.
We stripped out anything that wasn’t essential, keeping the focus on clarity and usability. Every feature had to solve a real problem.
TeamSnap (TeamToolKit) v2.0 - Availability Dashboard
TeamSnap (TeamToolKit) v2.0 - Availability UI Demo
From prototype to full-scale product
The prototype worked. Not just as a proof of concept but as a business.
Sparkplug accepted the TeamSnap v3.0 prototype in 2007, pitched it to an investor, and TeamSnap became a full-fledged SaaS company. Over time, it grew into a $20 million business with over 25 million users and serving over 19,000 sports organizations.
The craziest part? Many of the core features I built in that original version still exist today. That’s the power of getting the problem right from the start.
TeamSnap (TeamToolKit) v3.0
What I learned
Building TeamSnap taught me how to design products that solve real problems. It wasn’t just about writing PHP and MySQL. It was about challenging assumptions to find the real user pain points, designing with the customer in mind rather than just the client’s idea, and prototyping fast, testing early, and iterating based on real-world feedback.
It was the first SaaS product I helped bring to life, and it set the foundation for how I approach product design today.
Looking back
I still check in on TeamSnap from time to time. The company has grown and the platform has evolved, but the core remains the same. The same problems we uncovered in 2004, including scheduling headaches, team coordination, and parent communication, are still being solved today.
That’s when you know you built something that matters.