Why We Refactored Identity Without Touching the Teacher App
Large refactors are risky — especially when they sit at the centre of a production system.
When My Music Studio needed to support parents and students properly, the most obvious solution was also the most dangerous: rewriting the existing teacher identity system.
We chose not to do that.
The risk we wanted to avoid
The teacher app relies on a tightly constrained identity model with many dependencies:
• database constraints,
• row-level security policies,
• and many layers of accumulated assumptions.
Changing that foundation would have meant touching dozens of critical paths, with a real risk of breaking workflows that teachers rely on every day.
The alternative insight
Instead of modifying the teacher identity model, we recognised something important:
The platform already contained role-appropriate identity tables for parents and students.
Those tables:
• are naturally school-scoped,
• align with real-world relationships,
• and do not carry the same legacy constraints as the teacher system.
By linking these role-specific identities directly to authentication, we were able to:
• support multi-school parents,
• prepare for student logins,
• and leave the teacher app completely unchanged.
A clean separation of concerns
The result is a clear boundary:
• The teacher app continues operating exactly as before.
• The family hub uses identity models designed specifically for parents and students.
This separation reduces risk, simplifies reasoning about permissions, and makes future development safer.
Designing for continuity
In education software, reliability matters more than clever abstractions.
This refactor prioritised continuity: adding new capabilities without destabilising existing ones.
That philosophy guides all major architectural decisions in My Music Studio.