Two platforms launched. Stripe billing verified end to end. Eight critical security vulnerabilities caught and resolved before a single user's data was ever at risk. A 60+ table backend supporting coach certification, subscription-gated video, a full player development academy, leaderboards, realtime habit tracking, and an AI coaching assistant.

If you're a founder with content, a community, or proprietary IP that needs a backend built to last, this is exactly the kind of work Red Mage does best. Come find me on Contra or shoot a note to andres@redmage.cc.

Coleman Ayers is a basketball coach who builds. By the time he brought Red Mage in, he had already pushed a significant amount of frontend himself using Claude Code, and he knew exactly where his limits were. His words capture it better than any summary:

That's a founder who understands the difference between moving fast and building something that holds. He needed a backend partner who could own what he couldn't: schema architecture, Stripe's full subscription lifecycle, Mux video delivery, Row-Level Security, and the kind of edge function debugging that AI tools tend to get wrong or only partially right.

The engagement didn't start with a blank database. It started with an audit.

The existing schema had some patterns that would have created real pain down the road. Author fields were stored as plain text strings rather than UUID foreign keys, which meant RLS policies would have been unreliable from the start. Stripe data was scattered rather than normalized. There was no points ledger pattern, no separation of habits from habit logs, and no clean model for tracking video processing state through Mux.

Rather than building on top of those patterns, the first step was getting the foundation right. Schema changes were saved to versioned SQL files before anything was altered, so every decision was reversible. That approach set the tone for the rest of the project.

With the schema stabilized, the Stripe integration came next. This meant setting up restricted API keys scoped to exactly the permissions needed, building the checkout session and webhook edge functions, and then doing the actual hard part: making it work in production.

The bugs that surfaced were the kind that don't show up cleanly in documentation. Supabase's newer asymmetric JWT signing (ES256) broke the old HS256 verification approach. CORS preflight handling on the edge functions needed explicit treatment. Test and live mode price IDs were colliding. The distinction between Edge Function secrets and Vault secrets mattered and wasn't obvious.

Each of those got diagnosed, fixed, and documented. The end result was a complete flow: signup, paywall, Stripe Checkout, webhook, subscription state update, dashboard access. Working end to end, verified with real transactions.

Mux video came next. An edge function syncs the video library to Supabase on a schedule. Coach-submitted videos go through an admin approval queue before they're visible to subscribers. Signed URLs protect paid content from being shared off-platform.

This is the part of the engagement that mattered most, even though it wasn't the most visible.

Before the Coaches Platform went to beta users, a full pre-launch security audit turned up eight issues that would have been serious in production:

Admin tools were publicly accessible without authentication. The leaderboard was bypassing RLS by running with admin-level permissions. Analytics and transcript tables had no write restrictions. Supabase's leaked-password protection was turned off. Eight tables had RLS enabled with no policies written, which meant features like habit tracking, certifications, points history, and admin AI review were silently broken. Avatar and video storage folders were publicly browseable by anyone with a URL.

Most of these were one or two line fixes once identified. The value wasn't in the fix time. It was in finding them before users did.

The audit report was written in plain language rather than technical shorthand, because Coleman is a founder, not an infrastructure engineer. "Admin tools are publicly accessible without logging in" communicates the risk. "Missing RLS on admin functions" doesn't.

Phase 2 was a 31-table buildout for the BAM Virtual Academy player platform, built from a detailed spec. The schema covers a full content tree from programs down to individual cards, enrollment and billing tiers, workout sessions, habits and streaks with trigger-based automation, a points ledger, leaderboard, community posts and reactions, notifications, and a direct message system.

The access control pattern here had a specific wrinkle: a user gets content access if they're enrolled in a specific program OR enrolled in an all-access tier. Getting that fallback logic right in RLS without a policy conflict took some care. Realtime was enabled selectively on the tables where live updates actually matter: habits, messages, posts, notifications, leaderboard.

At project close, before handing off, Coleman got a set of forward-looking recommendations for when the platform starts scaling: branching off main in GitHub before every change, a staging environment on Vercel to catch issues before production, and a slower, more deliberate code review cadence as the user base grows. None of that was in scope. It was just the right thing to flag.

If you're a founder with content, a community, or proprietary IP that needs a backend built to last, this is exactly the kind of work Red Mage does best. Come find me on Contra or shoot a note to andres@redmage.cc.