Why we built SouthpawStrings
SouthpawStrings brings guitar reference tools and practice material into one place, with left-handed players included from the start. A player should be able to look at a fretboard in the orientation they use, find the shape they need, and return to the music without rebuilding their setup.
The site combines two related activities. The theory tools help someone explore scales, chords, intervals, and relationships. The practice player keeps a song's video, sheet, and playback controls together. The Desk lets those tools share a working area.
Why the tools share a desk
A scale diagram, chord reference, and player are often useful at the same time. Separate pages make a person repeatedly switch context and restore the settings they just chose. The Desk provides movable windows and shared music settings, while saved desks let a signed-in user return to an arrangement.
Left-handed support is part of the rendering and interaction model. The musical relationships stay the same; the view needs to match the instrument in the player's hands.
Why accounts are useful but not the starting requirement
A visitor can try the theory tools and use a practice library held in their browser. An account adds saved data across devices and the full practice workflow. Browser-held data and account data have different storage and recovery needs, which the site needs to explain before someone depends on them.
Practice content is personal. The account library encrypts sensitive practice fields and uploaded media at rest, and the privacy policy limits how that data is used. These controls do not make every profile field private or remove the need for secure access and backups. The trust policy explains the boundary.
Support is optional. Donations do not unlock product features. Earlier paid-tier designs remain in the historical record and should not be read as the current access model.
How the work developed
The repository records a progression from separate tools and practice screens to a shared Desk. Existing practice-library work supplied migration decisions for videos and sheets. Later changes addressed real interaction problems: windows that hid content, settings lost during account loading, and controls that worked differently on phones.
The shared window behaviour eventually became Desk Engine, a separate library. SouthpawStrings still owns the music tools, account behaviour, and visual design. That boundary allows window fixes to serve more than one application.
Changes pass through automated checks, a development environment, and a separate production promotion. Database changes have their own guarded procedure. Release records explain what changed; they should not obscure the introduction or substitute for a current operator guide.
Scope and limits
Browser-held practice data and account-held data have different recovery needs. Donations are optional and do not unlock features. Internal runbooks and deployment details are not public.
Continue reading
Read the case study for the architecture, security, and operations story, or open SouthpawStrings itself.
From the project’s documentation set. Internal runbooks and deployment records stay private — How I Build explains the boundary.