Consolidating a coaching business into a single Flutter app

Any authenticated user could search the full episode catalog regardless of their role. A free-tier member could find paid content, play it, and it would show up in their listening history — meaning even after fixing search, I had history entries exposing content they were never supposed to access.

The root issue wasn't a missing check — it was structural. The Algolia index treated every episode the same, and visibility was only enforced client-side, which meant anyone inspecting a network request or just typing the right keyword could reach content outside their tier. Fixing search alone wasn't enough, because the damage had already flowed downstream into user history.

I restructured visibility tagging across three layers — feeds, episodes, and user records — so that role-based access was consistent and enforceable at every level. Then I dug into Algolia's secured API key system and built a Cloud Function that mints scoped search keys per user, so each member's search index physically cannot return results outside their role. On the history side, I rewrote the history queries to filter against the user's current permissions, so even if a member had somehow played something they shouldn't have, it wouldn't surface in their feed going forward.

Search went from a shared index with client-side filtering — breakable by anyone with browser dev tools — to server-scoped keys with backend-enforced visibility across search, playback, and history. No member can see, play, or retain evidence of another tier's content, even if a future bug lets something slip through at one layer.

The first version of the transcript viewer dumped the entire transcript as a single block of text beneath the player. It didn't follow along with playback, it wasn't navigable, and once I had 1,200+ episodes with transcripts, it was clear that a wall of text wasn't useful to anyone.

The first problem was upstream. The transcription pipeline originally produced one continuous transcript per episode — no segments, no timestamps you could jump to. To make a tap-to-navigate viewer, I had to go back and rebuild the processor itself to output discrete 12-second segments, each with its own start time. That meant reprocessing the back catalog, not just changing the frontend.

The second problem was the viewer itself. Once I had segmented transcripts and built a player that highlighted the active segment, the highlight would drift off-screen during playback. The user would be listening, and the active segment would scroll out of view — so you'd have a "follow along" feature that didn't actually follow along. I set scroll parameters to keep the active segment locked within a target zone in the viewport and adjusted them through testing until the behavior felt right: the viewer tracks playback smoothly without jumping around or losing its place.

The transcript viewer went from a static text dump to a synchronized, tappable, searchable player that covers 99.8% of the back catalog. But it took two rebuilds to get there — one to fix the data, one to fix the experience — because I didn't know what the feature actually needed to be until the first version showed us what was missing.

I built a bulk move tool in the admin terminal so the coaching team could reorganize content — move episodes between feeds, shift entire seasons, hide or delete batches at once. The first time I used it on real data, it broke two feeds and roughly 80 episodes.

The issue was stale references. When episodes moved to a new feed or season, the old location references didn't update cleanly — some went null, others pointed to locations that no longer existed. The episodes effectively fell into a void. They weren't deleted, but they weren't visible in any feed, and the data that linked them to their original context — season assignments, ordering, feed metadata — was gone. The only way to recover them was manual database work, going through Firestore document by document to reconstruct where each episode belonged and restore the nulled fields.

After recovering the data, I went back to the drawing board on how bulk operations handle relational data. Moves now update all references atomically and validate that no episode is left orphaned before committing the operation. But the bigger lesson was that I had no way to know what had happened or when. So I built the admin change log — every bulk operation now records what moved, where it came from, where it went, and who triggered it. If something breaks again, I can audit the exact operation and recover from the log instead of manually reconstructing state from the database.

Two feeds and 80 episodes taught me that building the tool isn't enough — you have to build the audit trail at the same time, not after the first disaster.

Account provisioning was fully automated through Zapier: a new customer pays through Stripe or Affirm, the webhook fires, and a Cloud Function creates their account, assigns their role and access dates, and sends their credentials. Zero manual steps. It worked well — until it didn't.

Some customers came through paths Zapier wasn't watching. Payment plans with custom checkout flows, manual sales handled directly by the team — these would close a deal and then have no way to actually give the customer an account. The client services rep would have to come to me to manually provision in the database, which defeated the purpose of automating it in the first place.

I built a provisioning tool in the admin terminal where the team can create an account by entering a name, email, role, and start/end dates. The tool creates the Firebase Auth account, sets custom claims, writes the Firestore user document, and generates a temporary password to share with the new member. But the generated password was 12 random characters — functional for security, terrible for a first-time user trying to get into an app they just paid for. So I added a first-login prompt in the app that requires new users to set their own password on first sign-in, making the handoff seamless regardless of how the account was created.

The automated path still handles the majority of signups. But the manual provisioning tool means the team can handle every edge case — custom deals, gifted accounts, payment channels I haven't integrated yet — without waiting on an engineer or touching the database. The system is designed for the happy path but actually works for the messy one too.