ABC Fitness · Product engineering
Trainerize Profile Experience
A production rewrite of the coach profile, moving a long jQuery page into React so dense coaching information is easier to scan.- Role
- Software Engineering Intern
- Time frame
- Jun 2026 — Aug 2026
- Team
- ABC Trainerize
- React
- TypeScript
- Redux
- RxJS
- SCSS
Why this project
A high-visibility profile that had outgrown its stack.
Trainerize is the product coaches use to run training businesses and stay close to their clients. The user profile is one of the first surfaces they see: identity, credentials, social proof, and offerings all live there.
When I joined, that page was still a single long jQuery implementation. It was harder to maintain, harder to extend, and less consistent with the React design system used elsewhere. I took the work on because it was a real modernization problem in a multi-year production codebase, not a greenfield rewrite I could shape in isolation.
Goals & constraints
Parity first, then a clearer hierarchy.
- Move the profile into the React app with content and action parity for every existing section.
- Reorganize the same information into focused cards instead of one scrolling wall.
- Stay inside the production stack and design system so the rewrite did not create a parallel UI language.
- Ship the epic as reviewable pull requests, not one unreviewable migration.
Approach
Modernize in place, one section at a time.
The constraint that shaped every decision was the existing product. The profile already had users, data contracts, and a team review process. I needed a path that could land incrementally without freezing the rest of the web app.
Section-by-section migration, not a big-bang port
A one-shot rewrite would have produced an unreviewable diff and blocked QA until the end. I split the epic into isolated tickets so each card could go through design, engineering review, and QA on its own.
React with the team's Redux and RxJS patterns
The modern app already modeled async profile updates as observables feeding Redux. Matching that pattern kept the rewrite compatible with surrounding pages instead of inventing a new state model for one surface.
Design-system consistency over a pixel-perfect one-off look
When mockups disagreed with existing components, I confirmed intent with design and chose the direction that reused shared primitives. Consistency across the product mattered more than a profile that looked unique.
Implementation
What was hard, and what I changed.
Owning the rewrite end to end
I carried the profile from the legacy jQuery page through a redesigned React experience. Across the epic I opened 30+ pull requests on a platform used by 400,000+ trainers.
Keeping quality while moving fast
New profile modules and middleware landed with about 97% test coverage, which reduced regression risk as sections replaced the old page. Isolated git worktrees let me develop multiple sections in parallel without collisions.
Redesign, not only a port
Parity was the original scope. Once the shell and data path were in place, I proposed clearer empty states, more meaningful statistics, and a tighter visual hierarchy, then aligned engineering, design, and QA on the updated experience.
Outcome
A React profile ready for production review.
By the end of the internship, the modernized profile had gone through engineering review and into QA. Success here was not a single public KPI. It was parity, reviewability, and design-system consistency on a surface coaches actually use.
Reflection
Confirm first, then build.
The most expensive mistakes were the ones I almost made by inferring requirements from nearby code. Writing unclear points as specific questions, then aligning before a large implementation, was slower at first and faster overall.
I also learned that reviewability is part of the work. Splitting an epic so other people can actually read it is as much an engineering skill as the React rewrite itself.