Mindvalley Stories
Case Study · AI Mastery

A youth soccer parent coach built a working app and database with no coding past

A coach with no software background built a working Next.js prototype on an Airtable database they designed from scratch.

This coach works with the people nobody coaches: parents of competitive youth soccer players. Five months ago, briefing a developer was the only way they knew to build software. Now they have written a full spec, built a real database, debugged it against live data, and made a clickable demo of a gentle tool for parents.

Heike McGlothern
Founder of a life coaching practice for parents of competitive youth soccer players.

FieldSide Coaching: The Parent Companion

Before

They had built FieldSide Coaching on one belief: the relationship between a parent and child outlasts the game. They saw that the player already has a coach, while the parent, carrying real pressure of their own, typically has none. They wanted a tool to support parents between sessions, but had no software engineering background. Hiring and briefing a developer felt like the only path.

“Five months ago, briefing a developer was the only path I knew”

In their own words

The turning point

They chose to work spec-first, not vibe-first. Before any code was generated, they wrote out the problem, the users, the screens and the flows. With Claude Code, that spec became a working Next.js prototype connected to an Airtable database they designed themselves. When things broke, they had a source of truth to debug against, and they found and fixed three real integration bugs.

“Spec-first, not vibe-first.”

In their own words

After

They now have The Parent Companion, a working prototype for future 1:1 clients. Parents get a short check-in before a game or practice and a private reflections view, while the coach sees an anonymized view of themes across clients. They also built a self-contained click-through demo of both sides, so anyone can experience it without a login. It is not yet in a client's hands; it is the next step as the practice grows.

What it lets people do

Parents get a moment of support in seconds, glancing at their phone before a game, sometimes just a quote that needs no reply. There are no streaks or scores, only a quiet history of their own reflections. The coach can spot themes across clients without exposing anyone by name.

What they learned

They learned that building against a real business database is a different discipline from making a throwaway demo, and that writing the spec first is what made it possible. They also found that a working product and a demonstrable one are not the same thing, and making it clickable was worth the extra time.

“Building a real prototype against a real business database is a different discipline than building a throwaway demo.”

In their own words

FieldSide Coaching: The Parent Companion was built during AI Mastery.

Read the full submission
Project Description: An Interactive Prototype Built With Claude Code Against Real Business Data FieldSide Coaching is a life coaching practice for parents of competitive youth soccer players, built on one belief: the relationship between a parent and child outlasts the game, and protecting it is the whole point. The player already has a coach. The parent, carrying real pressure and uncertainty of their own, typically has none. The Parent Companion is a working prototype for FieldSide Coaching's future 1:1 clients, parents of competitive youth soccer players who, unlike their kids, have no coach of their own. It's designed to sit between coaching sessions: a short, low-effort check-in before a game or practice, a private "My Reflections" view of a parent's own history with no scores or streaks, and on my side, an anonymized, aggregated view of the themes surfacing across clients. It is not yet in a client's hands. It's the next step as the coaching practice grows. To let judges experience the real UX firsthand, not just read about it, I built a self-contained, click-through demo of both sides of the product: the parent's phone screens and the coach's desk view, toggled from one page, with no login or database access required to try it. ACHIEVEMENTS Designed and built the Airtable database the production app runs on. Not a pre-existing database I connected to. One I built myself, from scratch Took the project from a full written spec (problem, users, screens, flows) to a working Next.js prototype connected directly to that real Airtable database, spec written before any code Found and fixed three real integration bugs through live debugging against that real data: a linked-record matching quirk, a computed field that silently rejected writes, and a timezone mismatch in day-based scheduling Built a fully interactive, self-contained demo of the same experience, so a judge can click through it directly: sign in, a daily prompt, a response, a confirmation with a running season count, and a private reflections history, on the parent side; an engagement dashboard, an anonymized theme library, and a live prompt-management tool, on the coach side Sends a short prompt before a game or practice, or sometimes just a quote that needs no response. Every interaction takes seconds, built for a parent glancing at their phone, not sitting down at a desk Designed deliberately against gamification, no streaks, no scores, because the brand's core belief is that quiet presence matters more than managing outcomes Built a coach-facing engagement dashboard that surfaces aggregated, anonymized client themes without exposing any individual by name Did this with no prior software engineering background. Five months ago, briefing a developer was the only path I knew TOOLS: Claude Code, Next.js, Airtable (API and linked records), HTML/CSS/JS (the standalone interactive demo) METHODOLOGY: Spec-first, not vibe-first. The full functional spec came before any generated code. That's what made the debugging that followed real engineering: data-shape mismatches, write rejections, timezone logic, rather than surface-level prompting. I always had a source of truth to debug against. The interactive demo is a faithful, self-contained rebuild of that same spec and copy, built so it can be judged without needing access to the live app or its database. LEARNINGS: Building a real prototype against a real business database is a different discipline than building a throwaway demo. Spec-first is what made that possible. Building the reviewable version taught a second lesson: a working product and a demonstrable one aren't the same thing, and it was worth the extra build time to make this one clickable rather than just described.

Written 6 August 2026 Submitted by the storyteller

Every story is written by a Mindvalley student or by someone our teachers have worked with. How we collect and check stories

More from AI Mastery