NIL Live: Building and Delivering a Multi-Portal Platform

This is one of those case studies that isn't going to be a shiny, perfect thing. This is real, gritty, imperfect work — no finger pointing, no blame, just humans doing our best to deliver a genuinely cool product.

NIL Live is a platform that lets fans financially support college student-athletes — one-time payments, recurring support, milestone-based commitments — while giving athletes a simple, transparent way to receive and withdraw what they've earned through an in-platform wallet. It's a real product handling real money for real people, which meant there was no room to fake our way through the parts that were missing.

I was brought in as a project manager, with a secondary scope to serve as an "as-needed" designer — filling in gaps and making adjustments for the engineering team. I love when I get to lean into my years of UX/UI design experience, no matter how big or small.

Before this project kicked off, I wanted to know what I was actually walking into. As a project director, I'm used to scoping my projects from the start and managing expectations — mine, my team's, and the client's — up front. In this case, I was inheriting something that was already broken before it reached my team.

I audited everything available, logged my findings, identified risks, and wrote down my questions before a formal kickoff. Leaning into years of practice — both as a designer and as a digital project director — I had real concerns.

My biggest one: there were no user journeys. This was a complex platform — more complex than I understood at the time — and while the visual design already existed in Figma, none of the thinking behind it did: no wireframes, no sitemap, no documented research or benchmarking, nothing that captured why the product was built the way it was. The site had been visually designed. Why and how it was designed that way was undefined.

What I found

• No product manager or technical director

• No user journeys or sitemap — and no sitemap by phase either, so there was no shared picture of what belonged in the proof of concept versus the MVP versus what could wait

• No single source of truth connecting requirements, design, and what had actually been built — which meant no baseline to QA against

• Figma status itself was ambiguous — no way to tell which screens were current versus legacy from an earlier phase

• No agreed-on definition with the client of what "MVP complete" actually meant, or how success would be measured

There was no official "Product Manager" or technical director — we were a group of specialists missing some fundamental roles, and no defined strategy either, which is the piece a product manager would normally own. Side note: thank goodness for my own curiosity and appetite for continued education. Getting my Scrum Master certification and going through Jira certification a few years prior, on top of my background, turned out to be a godsend. I've never held the formal title of "Product Manager," but I knew what to look for, I knew what was missing, and I absolutely knew which risks were about to become real problems.

Before we could begin, I knew we needed some kind of foundation. I authored a Product Requirements Document (PRD) to help the team understand the most complex parts of the user flow, working with Claude.ai to synthesize the SOW, call notes, and scattered documentation into one source of truth — instead of five different understandings of what we were building. From that, I stood up a new Jira instance from scratch: epics, stories, acceptance criteria, dependency tracking, and a RAID log, so ambiguity had somewhere to go instead of just sitting there. I built a documentation hub in Confluence and a payments guide, synthesized from raw meeting transcripts with Claude's help, mapping exactly how Stripe, PayPal, and Zoho were supposed to talk to each other — closing a gap nobody else had closed, and one that would have caused real problems at launch if it stayed open.

All of this ran alongside the job I was actually hired to do — tracking budget and hours, running client status meetings, sending updates, staying on top of email, and everything else that comes with the title. There was no room in the budget to bring in another person to help carry the documentation and process-building load. That's the real reason AI played as deliberate a role as it did here — not a novelty, but a real necessity, given what one person could realistically carry alone.

Managing a team scattered across the world came with its own rhythm: early mornings and late nights. Engineering was in India, I was in LA, client management sat on the East Coast, the clients themselves were in Central time, and our back-end automations specialist was in the UK. Traditional daily standups weren't realistic across that many time zones, so we leaned on longer, less frequent sprint planning and collaboration sessions instead, plus a daily Slack channel where I made a point of modeling what I wanted from the team: what I'd worked on, what was blocking me, what was coming next. Because of the time difference, that usually meant sharing what got done today and what to expect tomorrow rather than real-time back-and-forth — and I expected my team to do the same.

Four time zones don't hold together on good intentions. They hold together on a shared rhythm — so I ran the team through the same six-step, two-week cycle every sprint: backlog refinement, sprint planning, dev and design support, QA testing, client review, closeout. Repeat. No matter what time zone someone was working from, they knew exactly where the project stood and what came next.

I pride myself on being a master at delivery — clean documentation, bug-free QA and UAT at the time of delivery, and a client who can take over because I set them up to succeed. Then came a QA failure that still stings to think about. I think of myself as a good host — I'd never make a guest wash their own dishes. As an agency person, if I'm delivering a project, it's complete; we have sign-off before it goes out the door. I'm not asking the client to find bugs in their own site.

I owned QA process and scope on this project — that responsibility sat with me regardless of who executed the day-to-day testing. Normally, I sit directly in the QA controls seat: deciding what gets tested, how, on which devices, by whom, and how bugs get tracked and prioritized. On this project, under a directive to protect a tight budget and avoid duplicating effort, I stepped back from that hands-on role earlier than I should have and trusted a lighter QA pass running in parallel with the build. That pass was checking for general issues, not testing against defined functional expectations the way a full QA process would have.

There was a QA charter in place before any of this — I'd written it going in, not after the fact. It still wasn't enough. We ran the parallel pass during the build, then a dedicated QA and UAT round before delivery, and the platform still went out messier than it should have. That gap between having a real process on paper and what actually got caught in execution is exactly why this stung the way it did — it wasn't that nothing was done. It's that what was done didn't hold. The client found more bugs than anyone should have to find after delivery. That's on me. I felt that, and it's not a feeling I want to feel again.

What I actually did about it: I went back through the charter a second time — sharpening device and browser coverage requirements, drawing a clear line between a blocking bug and a non-blocking one, and adding a dedicated regression pass before anything went back to the client — and re-triaged what was still open. I also built a Jira intake form so the client's UAT testers could log tickets directly, with a priority field running from P0 (launch-blocking) to P3 (future enhancement), instead of routing everything through email.

The platform launched once it actually met the bar — not on a fixed calendar. Left alone, the client would have kept polishing indefinitely; the budget wouldn't. We shipped a complete, working product within it.

“The title on the contract said Project Manager. The work was product ownership.”

What shipped

A complete athlete-and-supporter marketplace — wallet functionality, live payment processing, CRM integration, multi-portal architecture — live and operating together at launch. The client's team was trained and equipped to run it themselves. Zero to launched product, proof of concept to production, in seven months, with a team of five.

What I learned

Messy as it was, I'm still proud of it. My team and I learned a lot. No one got thrown under the bus — even if I felt run over at times. The project manager takes the hit, and as a recovering people pleaser, that isn't easy. But that's what therapy is for.

I used AI deliberately here, not as a novelty — Claude built the PRD and the payments guide because there was no version of this engagement where I could staff my way out of the documentation load instead. That constraint forced real tradeoffs: what got documented and built first was whatever was blocking someone else's work, not whatever felt most urgent to me personally. The QA process got rebuilt the moment I knew it had to be, ahead of everything else competing for my time.

I don't want this to read like tidy hindsight — the "I knew it all along" version that's easy to say after the fact and hard to actually believe. So here's the part that makes it real instead: I flagged this exact risk in writing, before the project even kicked off — no QA baseline, no source of truth, this was going to cause problems if it didn't get fixed. That's not a story I'm telling now; it's dated, and it exists. Knowing it and having the resourcing to fully prevent it turned out to be two different things, especially under a directive to protect the budget. That's the actual lesson: flagging a risk on paper isn't the same as having the authority to resource it properly, and next time, that's the gap I want to close harder — pushing on resourcing a known risk, not just documenting it and hoping the mitigation holds.