Turning a shared frontend into code teams could own.
- 01Scattered ownershipShared frontendFEA-01FEA-02FEA-03FEA-04FEA-05FEA-06FEA-07FEA-08FEA-09Feature code sits wherever it landed, so every change crosses teams.FIG. 01 / 1 OF 3
- 02Repeatable transformationFEA-01FEA-02FEA-03FEA-04FEA-05FEA-06FEA-07FEA-08FEA-09One regenerable codemod moves each feature to its owner.FIG. 01 / 2 OF 3
- 03Localized ownershipTeam ATeam BTeam CFEA-01FEA-02FEA-03FEA-04FEA-05FEA-06FEA-07FEA-08FEA-09Each team owns and reviews its own area.FIG. 01 / 3 OF 3
Podium’s primary frontend had grown organically. Team-owned features were distributed across the application, which created cross-team review requirements and made a long-running manual reorganization vulnerable to repeated merge conflicts.
I designed a repeatable codemod that moved feature work according to ownership, updated imports and other references, and left the application compiling and running as before. Because the transformation could be regenerated, teams could review the intended result and reapply it after conflicts instead of repeatedly repairing a manual migration.
Work became more localized. Teams could establish more granular CODEOWNERS, reduce unnecessary multi-team approvals, and move faster inside their own areas of responsibility.