SouthpawStrings.com is a practice website made for left-handed guitarists first. It has interactive music theory tools, user accounts, playlists, sheet music, uploaded practice audio, and the Desk (a workspace where tools open as windows you can drag and arrange). It also has ways for supporters to help fund it. It is live, public, and gaining real users.

I wrote the application myself, using well-known programming frameworks. It is not put together from a website builder, a content management system or a pile of plugins. I designed the product, how its data is stored, what gets encrypted, how it is packaged and hosted, its network rules, and how new versions are released. Building it this way keeps the design easy to understand. It also leaves me free to shape the product around what left-handed guitarists actually need.

It is entirely a personal project. I built it outside work hours, on my own equipment, domains, accounts, licences and hosting. No employer or customer code, data, systems, documentation or confidential information was used anywhere in it.

This page explains what I built and how. It shows a project built to order, kept secure and well documented, and run to the standard of a professional service.

The product

From resource hub to practice platform

SouthpawStrings brings left-handed theory, your own practice material and real playback tools together in one place. You can go from learning an idea to rehearsing it with a song.

Left-handed firstInteractive theory toolsTools for scales, modes, chords, arpeggios, voicings, intervals, a metronome and the fretboard. All are designed around left-handed players, not added for them as an afterthought.
Personal libraryPlaylists, songs & sheetsUsers can sort songs into playlists, attach several PDF or text sheets to a song, and scan a sheet for chords. The site remembers where they were between sessions.
Practice playerOne player, several layoutsYouTube, uploaded audio, sheet-only and combined layouts all use the same controls. Each layout supports play and pause, page turns, A–B loops, previous and next, and control from the keyboard or a foot pedal.
Real audio toolsSlow down without tuning downFor practice tracks that users upload privately, the player can slow the music down without changing its pitch, or change the key. It shows the waveform for quick navigation and loops exactly where you set it.
The DeskA practice space of windowsPlayers open theory tools and the full practice player as windows on a desk. Windows can be dragged and snapped into place. Layouts save to the player’s account and reopen on another device. The Desk proved so useful that I turned it into its own library, @denley/desk-engine, which now also runs this site.
Inclusive designThemes, accessibility & languagesLight and dark themes, optional colour profiles, layouts that adapt to any screen, and full keyboard support. Early Spanish, German and Japanese translations let more people use it.

The stack

Modern, typed, maintainable

The site is built with Next.js 16 and React 19, two widely used frameworks for building web applications. All of the code is written in TypeScript, which checks that data has the expected shape, from the screen down to the database. Styling uses Tailwind CSS and shadcn/ui components.

Data lives in a PostgreSQL 16 database. The code reaches it through Prisma 7, a library that turns database tables into typed code. Every change to the database’s structure is a numbered script that only moves forward. CloudNativePG runs the live database. It records every change continuously and takes a full backup each day, so I can restore the data to any point in time. Separate exports and offsite copies give a second way back. I have practised restoring the data, so I know it works.

Auth.js handles sign-in. People can use an email and password, or sign in with Google, Apple, Microsoft or Facebook. Each provider gets the protections it supports. These include PKCE, which stops a stolen sign-in code being used by someone else. Apple’s sign-in secret is created fresh from its signing key when needed, rather than stored for a long time.

The site is packaged as locked-down Docker containers (self-contained bundles of the app and everything it needs). These run on Kubernetes, software that starts, restarts and scales those containers. Cloudflare sits between the site and the internet. A self-hosted pipeline tests each change and releases it to development automatically. I use k6 to load-test the site with short checks, gradual ramps, sudden spikes and long sustained runs. That way I know its capacity rather than guessing.

Security by design

Built secure, not patched secure

I built security in from the first line of code. Later I ran a full security review of the code and fixed every significant finding.

Stored dataEncryption of each fieldUsers’ practice data and uploaded files are encrypted with AES-256-GCM, a strong standard cipher, before they reach the database. The app also keeps a one-way fingerprint of some values. That lets features look things up without decrypting anything.
PasswordsModern password handlingPasswords are never stored. The site stores only a scrambled, one-way version (a salted scrypt hash). It checks passwords in a way that gives attackers no timing clues. Password reset links work once, expire, and are stored scrambled too.
IdentityTwo-factor & safe account linkingPassword accounts must turn on two-factor sign-in (a code from an authenticator app) before they can save practice data. They also get single-use recovery codes. If a sign-in provider can’t confirm someone’s email address, the new account waits until they confirm it. Adding or removing a sign-in method needs fresh proof of identity and is logged. The site never lets you remove your last way to sign in.
Browser protectionsStrict browser rules on every pageEvery response tells the browser to use only secure connections, to run only approved scripts, and to refuse to show the site inside other sites. It also stops the browser guessing file types, and limits what it shares and which features pages can use.
Stopping abuseAttempt limits & human checksSign-in and sign-up limit how many attempts each internet address can make. They also use Cloudflare Turnstile, a check that a real person is there. Error messages are deliberately vague, so attackers can’t use them to find out who has an account.
ReviewReviewed, tested, fixedA full security review read through the whole codebase: sign-in, the app’s interfaces, encryption, the database design, browser rules and containers. The findings were fixed and written up. An automated test suite also checks every change before it can go in.

Operations

Run to production standards

A website is only as good as the way it is run. I run SouthpawStrings the way a company would run a professional service.

Public accessNo open doorsThe server connects out to Cloudflare, and all visitors arrive through that connection (a Cloudflare Tunnel). No ports are open for the internet to connect in, anywhere.
HostingA dedicated serverThe live site runs on a dedicated hosted server using k3s, a lightweight version of Kubernetes. Containers run without admin rights. Each release names the exact build it uses. Network rules block traffic between parts of the system unless it is specifically allowed.
EnvironmentsProduction and development kept apartThe live site and a restricted development copy each have their own space, database, credentials and release route. Safety scripts block destructive actions against the live site by default.
ReleasesRepeatable, checked releasesEvery proposed change must pass type checks, style checks, tests, database-safety checks and a full build. Development updates automatically. Once I approve a release, the live site gets the exact build that was tested in development. A backup is always taken before any database change.
CapacityLoad-tested, and grows with demandk6 tests range from quick checks to long sustained runs, so I know the site’s limits rather than guessing. As traffic rises, the site starts extra copies of itself to share the load.
ContinuityAlways on, always backed upThe database has a standby copy that takes over automatically if the main one fails. Every change is recorded continuously, a full backup runs daily, and separate copies are kept offsite. I have practised a full recovery. The site also has health checks, an audit log, and written guides for database changes and recovery.

Documentation

Documented like it matters

Engineers love documentation, and businesses need it. A system nobody wrote down is a risk. It can’t be audited, it can’t be handed over, and it depends entirely on whoever built it. So I document SouthpawStrings the way a commercial system should be. Every operating procedure is written down, stored with the code, and kept up to date as the site changes.

That includes a release guide, database safety procedures, and a setup guide for every outside service the site uses. It also includes the security review and its fixes, an overview of how the system fits together, and a formal handover document. Another engineer could pick the site up from scratch and run it.

That habit isn’t specific to this project. Accurate documentation, guides anyone can follow, and a handover pack stop any system depending on one person. If it isn’t documented, it isn’t finished.

Still moving

What’s been shipping lately

The site has had more than 175 numbered releases. It still changes in small, tested steps, and each release has a changelog entry that records why. I moved the core of the practice Desk into its own library, @denley/desk-engine, and the site now uses that library. Since then the whole site has moved onto the Desk. Windows can now fill the whole screen and remember the size a player chose. They also move visibly when they close, minimise, restore and roll up.

September added a tuning and capo system and a choice of note names: letters, Do Re Mi, or German notation. It also added a realistic fretboard drawn by the graphics card, and English, Spanish, German and Japanese in the language switcher. A person still approves every live release, and each one names the exact build it uses.

Much of that polish came from watching real people use it and not settling for a first attempt. I rebuilt the language switcher after its first version tested badly. I fixed the snap previews so they show exactly where a window will land. When the Desk rearranges windows, it now keeps the rows a player can see. The standard is simple: it has to feel right, not just work.

How it was delivered

I built SouthpawStrings with AI tools, but under my direction. AI helped me move faster on code, documentation and testing. I reviewed the work, set its limits, and owned every decision. I apply the same rule to all my professional work. AI speeds things up. It never replaces engineering judgement, security limits or accountability.

Professional relevance

What this demonstrates

SouthpawStrings is a music project, not an IT business. But it is honest evidence of how I work. I gave a website for guitarists encrypted data, two-factor sign-in, a network that trusts nothing by default, and a careful release process. That says something about the standards I apply. Documentation, privacy, security, automated releases, good design and maintainable code matter to me, even on a hobby project.

View my CVSee it live · southpawstrings.comRead the public summaryRead my bio