Repertoire App

Problem

Music teams often operate across multiple contexts (church worship team, personal practice, community choir). Users need complete data separation between groups while maintaining a unified app experience.

Solution

Architected a multi-database system where each group gets an isolated Room database with its own songs, singers, and assignments. The app layer handles database switching transparently, ensuring data isolation without complicating the user workflow.

Problem

Music teams needed shared access to song libraries across multiple users and devices. Each group required isolated data with secure authentication, and the system needed to handle concurrent access without data conflicts while maintaining offline functionality.

Solution

Implemented Firebase Authentication for secure user management with custom claims for role-based access. Architected a hybrid local-first/cloud-sync approach: Room database provides offline reliability, Firestore handles multi-device synchronization. Group creation and joining workflows use Firebase Auth with secure document-level permissions, enabling team collaboration while maintaining strict data isolation per group.

Problem

Music workflow involves interconnected entities: songs, artists, albums, singers, assignments, tonalities, BPM, and rehearsal metadata. Additionally, the same song often requires different keys for different singers—Singer A may rehearse in C while Singer B prefers D. Naive data modeling leads to duplication and inconsistent state.

Solution

Designed a normalized domain model with clear relationships and personalized key handling. Songs belong to artists and albums; singers have assignments linked to specific songs with individual key and BPM metadata. This enables personalized rehearsal preparation (same song, different keys per singer) while maintaining a single source of truth for song data and supporting powerful filtering ("songs in C major for alto voices").

Problem

Musicians worldwide use different notation standards: Anglo-Saxon (C, D, E, F, G, A, B) versus Latin/Solfège (Do, Re, Mi, Fa, Sol, La, Si). The app must display and transpose chords in both systems without duplicating song data or complicating the data model.

Solution

Implemented a canonical chord representation with presentation-layer transformation. Chords stored in normalized format, translated at the UI layer based on user preference. This enables seamless key transposition in either notation system while maintaining single source of truth for song data—supporting international music teams without data duplication.

Problem

Rehearsal preparation often happens offline — in practice spaces with poor connectivity. The app must function fully without network dependency.

Solution

Built on Room persistence with a local-first architecture. All CRUD operations write to local database first; sync operations (when online) are secondary. The UI observes local data sources exclusively, ensuring immediate responsiveness regardless of connectivity.

Problem

Workflow apps require real-time UI updates as data changes (new song added, singer assigned, rehearsal notes updated). Traditional callback patterns create tangled dependencies.

Solution

Implemented MVVM with Repository Pattern using StateFlow and LiveData. Domain changes propagate reactively through the architecture layer, and the UI observes immutable state snapshots. This enables complex workflows like filtered lists that update instantly when underlying data changes.