4thCoach

Sports clip coaching & playback for everyone.

Comment

What it does

Sports clip coaching & playback for everyone. Drop a clip in, get a coach back: 4thCoach classifies the sport itself, finds the seconds worth watching, loops them, and coaches each one in language matched to the player's skill level. A first-season player and a seasoned one get the same fault explained differently.

Findings come back as a vertical feed of short looping moments, each already framed on the coaching moment, and each one speaks its coaching aloud as it plays. Narration is how the coaching arrives rather than a setting you go find, so the kid who is actually the player can use it without reading a paragraph. If a piece of advice doesn't land, you can ask for it deeper or plainer. Every moment takes a thumbs up or down with a reason.

Families with more than one kid get one library that stays sorted. Every clip belongs to a player, and the history is tracked per player, so one kid's swing is never scored against their sibling's.

Then it remembers. Every new clip is judged against every pattern already tracked for that player. A fault gets confirmed, then fixed, and if it comes back it reopens itself.

And it currently covers nineteen sports and seventy-three authored movements: baseball, basketball, boxing, cricket, diving, field hockey, flag football, golf, gymnastics, pickleball, running, skateboarding, soccer, softball, swimming, tennis, track and field, volleyball, and weightlifting. The list isn't fixed, either: a movement we've never seen before is accepted and classified rather than refused, and a sport earns deeper authored coaching once real users keep bringing it.

Inspiration

When I was younger, I was a diver. Most practices you'd climb out of the pool and watch the dive you just did on a monitor at the side. You saw it, then you went and did it again. That feedback loop helped me get better.

My kids play lots of sports. They hardly ever watch themselves play. I have hundreds of videos of them on my phone, and watching the clips is a poor experience. When I'm at the sideline and something's off, I rarely know what to tell them, or the coach explains it in a cue or tip the kids don't get. Private lessons are so expensive now at $75–150 a session.

I wanted to hand the elite player's video-and-coaching loop to my kids, and to everyone else, and let them learn at their own pace.

I also wanted to know whether I could carry a whole product myself: the design, the product decisions, the software, and the business and operations around all of it, rather than one slice. A contest with a deadline was the thing that made that a real test instead of another weekend.

How I built it

4thCoach started as a weekend project, a rough iOS spike that could watch a clip and point at something in it, one of several I'd started over the years. The contest was the reason to pick it up, and picking it up meant answering the questions the prototype had gotten to yes: how do you look at a clip and find what's actually worth saying, how do you show that back to someone so they watch the right two seconds instead of scrubbing, and how do you close a loop so the next answer is better than the last one. How do you make reviewing a delightful experience? How would I price this? Everything built since is one of those questions.

One person, twelve weeks, with AI at every layer. I have a full-time job, so most of this had to run without me:

  • The product brain is Gemini on Vertex AI: sport classification, movement analysis, coach chat, and spoken coaching, behind an LLM routing chain that escalates to more advanced models for complex motions.
  • The backend is Firebase: Cloud Functions, Firestore, Cloud Storage, BigQuery billing export, eighteen scheduled jobs.
  • The app is SwiftUI, with Apple's Vision framework doing on-device pose estimation that anchors each finding's loop to the player's body.
  • I did the design and the brand myself. Screens and website started as text prompts in Google Stitch, got refined in Figma, and were finished in code. The palette, type, and spacing live in code rather than in a design file, so the look is versioned with the app and a rename can land everywhere in a day. Marketing concepts and imagery came out of Nano Banana, Pexels, and the demo video concepts out of Veo. The one design decision I'd defend hardest is that the coaching speaks itself while the clip loops, instead of sitting in a paragraph you have to choose to read.
  • AI wrote most of the code.
  • The agents are the team I don't have. No employees, no contractors, no co-founder, and I'm not available for most of the working day, so the parts of a business that need doing on a schedule went to fourteen scheduled agents rather than to nobody. They run in GitHub Actions overnight and while I'm at work, reporting into rolling GitHub issues that are the company's dashboard: a daily production-health digest, a weekly security sweep, nightly cost reconciliation off the billing export, an architecture review, a documentation-truth audit that checks our own docs against the code, a funnel report, an App Store digest. One of them opened an issue when coaching quality regressed overnight, tracked it for three days, and closed it itself when quality recovered. It's the only reason a one-person business has a daily operations report at all.
  • AI is also structurally forbidden from shipping. A permissions gate plus a pre-tool hook block every agent from deploying to production.
  • The users are mostly children, so the guardrails are written into the system rather than into my intentions. A neutral age screen runs before sign-in, so no account exists for a self-identified minor. Every production call is pinned to Vertex AI by a hard guard in code, not configuration. The LLM is steered away from commenting on a kid's body and toward their movement. Source video deletes itself at 180 days while the coaching record persists, and unsafe-response reports route to their own queue instead of competing with feature requests. None of it is load-bearing for a feature, which is why it has to be structural: the cost of a bad answer scales as fast as the good ones do.

And I put it in front of real people while it was still rough. Testers were in the app from mid-July, and every piece of feedback is logged verbatim in the repo, deliberately separate from the issue tracker, because a customer saying something doesn't automatically make it a roadmap item. That loop redirected the product more than any planning session did. The looping moment, the mechanic the entire product is built around, came from one offhand line from a dad in July: "would be nice when pin pointing an issue, the clip would be viewable".

Challenges

The first challenge was choosing what to build. I had several unfinished weekend projects and only twelve weeks, and the impressive-sounding ones weren't the ones I'd still care about in week nine. I picked the problem I actually had at the sideline (a spike that could watch a clip of my kid and point at something in it) and set the scope at what a person with a full-time job could finish rather than what would demo best.

Choosing the buyer took longer and cost more. The May plan was coach-led: coaches validate the product and refer families, families pay. The coach product was designed and shelved; it needed roster surfaces that didn't exist, a longer sales cycle, and a heavy coach on the expensive model initially modeled out negative. Shelving it is why there's one finished product to submit instead of two half-built ones.

Then the cost of being wrong about a clip. Accuracy versus cost per clip is a 10x spread, and finding the balance that still makes a viable business took most of the model-routing work.

Then pricing it, which took longer than anything else on the business side. People expect an app to cost one predictable number a month. Software built on AI doesn't work that way. My costs go up every time somebody uses it, so the more a customer loves the product the more each one costs me. Those two facts point in opposite directions, and most of the ways to reconcile them are bad: meter it and every upload becomes a decision about money, which kills exactly the habit the product needs; charge flat with no limits and a single heavy user can quietly cost more than they pay. What I landed on is a flat subscription with a daily ceiling on analyzed clips. The cap sits far above what a real family does in a day and low enough that misuse can't run away from me. The free tier is the same shape with a lower ceiling. It's the simplest structure a user can accept in five seconds that still survives its best customer. There's a good chance this model will change, but it's the best I have for now.

Then keeping the names straight, which got harder the more the thing evolved. The product carried four names in twelve weeks (Caliper 606, YouPlai, Plai, and finally 4thCoach), and the terminology inside it moved just as much. The few seconds the app pulls out of a longer clip had no obvious name. Neither did the thing the coach says about them, or the fault it tracks across a season. Every rename has to land in the app, the help docs, the website, the database, and the prompt on the same day, or two screens end up calling one thing two names. The paid tier alone went Family → Plus → PLAI+ → 4thCoach+. The last rename earned its cost. 4thCoach names the seat the product takes: your player's 4th coach, alongside their real coach, their parent, and the player themselves. It answers the first question every coach asks, because it stands alongside them rather than replacing them. It also cleared an internal trademark search before it shipped.

The one I haven't solved is retention. One clip is a trick. The answer we built is the pattern ledger: every new clip is judged against every pattern already tracked for that player, a fault moves watching → confirmed → fixed on evidence alone, wins fire once, and a regression reopens itself. Findings deliberately outlive the footage, since source video is deleted after 180 days while the record persists, so the thing that accrues is the history, and it can't be exported or rebuilt from scratch. Whether that actually brings users back is the open question; we have the instrumentation and not the cohort.

Nobody knows you exist, and that is the plainest challenge of all. Acquisition so far has been me: printing fliers, going to sporting events, and talking to parents and coaches between games, alongside a public site. No sales team, and no audience to launch into. It has worked about as well as that sounds: twenty-nine users, most of them testers and family. The cost side of this business is proven and the demand side is not. It has a distribution problem, and that is the whole of the next phase.

The engineering was hard too:

Finding the right seconds of video was the hard problem, and I got it wrong twice. The first approach measurably worked, and I threw it out anyway when the backend moved. Then real feedback showed the second one was wrong for about half the findings, in a way I hadn't anticipated and would never have found without users watching real clips of their own kids. Fixing it took a third rebuild. It still isn't completely solved, which is why you can drag the loop window yourself.

Consistency is harder than correctness. To show a user a pattern across a season, the model has to call the same fault by the same name every single time, and it will not do that on its own. Describe one thing three ways and it looks like three problems. Getting that stable took a meaningful slice of the prompt work, plus an agent that still pings me when the naming starts drifting.

And I had to build the instruments before I could see anything. When a finding came back wrong, there was no way to answer why without digging through raw records by hand: which clip, which model served it, what that player's history already said, what the model was actually given. That's fine for one clip and hopeless past a dozen, and there was no support team to absorb it. So a real slice of the twelve weeks went into tooling rather than product: an admin dashboard for the view across all users (cost per day, the funnel, which users are stuck) and a read-only bridge that hands an AI agent the same audited data directly, so it can pull up a user, read that session's findings, fetch the clip, and cross-check how the fault was labeled without me relaying anything by hand. It can only read, never write, and every access is logged against its own identity. Building the tools to understand the product is time not spent on the product, and I'd make the trade again: a bad finding went from a shrug to a question I can answer in minutes.

Apple was the dependency I couldn't engineer around. Getting through App Store approval as a new developer proved to be its own project. Each review costs days you can't get back on a twelve-week clock. That's the part that stings, because all of it sits directly on top of revenue.

What I learned

How far one person can now reach, and what that obliges. Twelve weeks, one person with a full-time job, under $750 of spend, and the output is a production service that any family with an iPhone can install today. No funding, no hiring, no permission, no distribution partner. That is what's new about building right now.

The hard part was never any one decision. It was how many of them there are. Branding, the name, what to charge, forming the company, which sports to author, which model to route to, what to cut. Each one is small enough to settle in an afternoon and consequential enough that getting it wrong costs a week, and there is nobody else to make any of them. What I actually got better at over twelve weeks wasn't engineering. It was holding product, design, pricing, compliance, and operations in my head at once and deciding at the speed the calendar demanded, knowing some of those calls were going to be wrong.

AI is remarkable and it is mediocre, and which one you get depends almost entirely on what you point it at. That's the lesson I'd rather not have learned, because it means the tool never lets you stop paying attention. The agents slowed me down about as often as they sped me up: confidently wrong answers that read as finished work, and long stretches where the real problem was that I hadn't said clearly enough what I actually wanted. The related cost is that the project moved fast enough that it was hard to bring anyone along.

My kids use it, and their honest reaction is the most useful data I have. They do watch. The spoken coaching lands, and so does the playback. And some days they aren't in the mood to review anything, which is entirely fair and is the part no amount of engineering fixes. Removing the price of coaching does not create the appetite for it.

And the cost of not knowing what I was building. I spent too much of the early window unsure what this was, and the version I'm submitting only came together in the last stretch. That is the whole reason the deadline arrived before I could find out whether anyone would pay, or whether this has product-market fit at all. Twelve more weeks starting tomorrow and I'd put it in front of users in week one instead of week eight, not to launch sooner, but to spend the time I bought at the end on revenue and validation rather than on the build.

What's next

Distribution. The product surface is largely solid and almost nothing has been spent on reaching anyone. The next phase is the first arms-length customers, then the coach tier I deliberately shelved to serve one user well first. I want to continue to refine the product surface as more users and sports come on board.

Built With

Share this project:

Updates