← Selected work · Nov 2025 – Feb 2026
Three Degrees.
A members-only property platform with a broken AWS to Supabase migration. 1,640 users locked out. The previous developer was gone. I diagnosed the GoTrue bug, restored every user, and shipped working auth.
- Period
- November 2025 to February 2026 (~3 months, 41+ hours)
- Role
- React Native Migration Engineer. Vetted match via Arc.dev.
- Client
- Noelle (Three Degrees)
- Stack
- React Native, Expo, Supabase (PostgreSQL), AWS Aurora MySQL, AWS Cognito, TypeScript, SQL
- Status
- Shipped. 1,643 users restored, magic links and password reset working for every migrated user.
Overview
Three Degrees is a members-only property-sharing platform. The previous developer started an AWS (Cognito + Aurora MySQL) to Supabase migration and left it in a broken state. Roughly 1,640 users were locked out of the new system. I was brought in via Arc.dev to finish what was started and ship working auth without losing anyone.
Problem
The migration had failed quietly. Users existed in different shapes across two data sources: Mailchimp had 1,650 subscribers, AWS had a 2,144-user export, and the live Supabase had a partial subset. Magic links and password resets did not work for anyone migrated. The cause was not in the project code. It was three separate root causes inside Supabase’s GoTrue auth service that nobody had isolated.
Constraints
- Real users locked out. Every day this took was a day of lost trust.
- No clean source of truth. The two exports overlapped but did not match.
- Hourly engagement billed through Arc.dev. Diagnosis time had to be paid time, and it had to land on the actual problem.
- The fix had to be deterministic and re-runnable. No manual one-off scripts the client would inherit.
Decisions
- Treat the user-identity problem as a data reconciliation problem first, GoTrue second. Cross-reference Mailchimp (1,650) against the AWS export (2,144), then against live Supabase. Build the canonical user set before touching auth.
- Reproduce the broken auth flow locally. Isolate which user records produced which failure mode. Three distinct GoTrue bugs, three distinct fixes.
- Build user restoration as bulk SQL in four numbered, idempotent steps. Anyone who reads the script later can run step 3 without re-running step 1.
- Hand over a tiered bug audit (Critical / High / Medium / Low) so the next developer or maintainer knows what is urgent and what is hygiene.
What I built
- Complete AWS to Supabase migration architecture and execution
- Cross-reference between Mailchimp and AWS Cognito user exports to define the canonical user set
- Diagnosis of GoTrue internal bug blocking ~1,640 users (three separate root causes)
- Bulk SQL migration scripts restoring 1,643 user profiles in four idempotent steps
- Auth fix: magic links and password reset working for every migrated user
- Comprehensive bug audit (Critical / High / Medium / Low tiers)
- Full handover documentation
Result
- 1,643 users restored (1,566 approved, 65 applied, 12 pending)
- Zero data loss
- Magic links and password reset working for every migrated user
- 41+ hours billed via Arc.dev, all on the actual problem
Reflection
When a migration is broken, half the time you are not debugging the system you inherited. You are debugging the previous engineer’s mental model. Once I separated “what the data says” from “what the previous code assumed,” the GoTrue bugs became three concrete things to fix instead of one fog. The other lesson: when users are locked out, spend the hour reading every support email and identifying the human cost. That hour pays itself back the second week, when you know exactly which fix to land first.
Stalled migration to rescue?
Broken Supabase auth, half-finished schema moves, users locked out: this is the shape of work I take on most often.