Case study — 05/06

Protecting momentum on a fixed-scope build that was already working

A gamified AI nature-ID app, inherited mid-flight, where the job was keeping an already-aligned team moving through the handoff.

ClientConsumer mobile app — AI-powered recognition, gamification and social features for a hobbyist audience
RoleProject Manager
TeamFreelance UI/UX designer
Also on LinkedIn

Context

Four milestones, scoped end to end: branding, core modules (auth, onboarding, an interactive map), collection and gamification mechanics, and monetization. Fixed budget, with a flat management fee built into the model, about five weeks of active delivery. I inherited the project mid-flight from another PM, with a functionality map already built out, an active Figma file, and a freelance UI/UX designer already engaged.

The stakes

Most of my case studies involve fixing something. This one was healthy from the start. The client knew the product cold, came in with clear context, answered clarifying questions immediately, and stayed present in Figma comments instead of disappearing between calls. The designer matched that level, strong enough in UX thinking to hold his own on product decisions instead of just executing a spec.

That kind of alignment is rare, and it carries its own risk. A team already moving well can lose pace fast if a handoff is handled carelessly, or if a shared resource goes unmanaged until it becomes a conflict. My job was to protect that alignment through a mid-project handoff without losing any of the team’s velocity.

What I did

Audited before touching anything. Coming into an active project, my first move was going through the existing functionality tables and Asana structure end to end, so the handoff itself didn’t cost the team any velocity.

Flagged the shared-resource risk early. The designer was a freelancer working across other agency accounts at the same time. I mapped the overlap ahead of time and built in workload visibility, rather than waiting to react to a scheduling conflict once it hit.

Kept building through async gaps. Client feedback came almost entirely through WhatsApp, with occasional lag. The team kept advancing modules against established product logic during those gaps, and auth and onboarding both hit 100% ahead of schedule.

Separated the scope-expansion conversation. When the client raised interest in expanding into full development, I flagged it as its own scope decision, requiring its own proposal and timeline, kept apart from the live design sprint.

Outcome

  • Delivered on schedule with no margin erosion
  • No communication breakdowns across a five-week, WhatsApp-driven feedback loop
  • Auth and onboarding modules complete ahead of schedule
  • The scope-expansion request captured as its own proposal, kept out of the live sprint

What I’d do differently

I’d set up workload visibility for every shared freelancer at kickoff, on every project, instead of building it in reaction to this one. The conflict risk repeats across projects; there’s no reason to wait for the first warning sign before building for it.

Available for contract