SouthpawStrings.com is a left-handed-first resource and practice platform: interactive theory tools, user accounts, playlists, sheet music, uploaded practice audio, a window-manager practice Desk, and community funding integrations. It is live, public, and gaining real users.
The application is purpose-built on established frameworks, rather than assembled from a CMS, site builder, or plugin-heavy platform. Its product design, data model, encryption boundaries, container images, Kubernetes manifests, network rules, and release process were all engineered for this specific service. That keeps the architecture understandable and the product free to evolve around what left-handed guitarists actually need.
It is also entirely a personal project: built outside work hours, on my own equipment, domains, accounts, licences, and hosting. No BTG or customer code, data, systems, documentation, or confidential information was used anywhere in it.
This page walks through what was built and how — a technical case study in bespoke, secure, documented engineering operated to production standards.
The product
From resource hub to integrated practice platform
SouthpawStrings now joins left-handed theory, personal practice material, and real playback tools in one coherent workflow — from learning an idea to rehearsing it with a song.
The stack
Modern, typed, maintainable
The application is built on Next.js 16 (App Router) with React 19 and TypeScript throughout — a fully typed codebase from the UI down to the database layer. Styling uses Tailwind CSS with shadcn/ui components, and data lives in PostgreSQL 16 accessed through the Prisma 7 ORM (over a connection-pooling driver adapter) with versioned, forward-only schema migrations. The production database runs as a two-instance high-availability CloudNativePG cluster — a primary and standby with automatic failover. Continuous WAL archiving and daily base backups provide point-in-time recovery, while separate logical and offsite copies add another recovery path. Restore capability is drilled, not assumed.
Identity is handled by Auth.js: email/password plus OAuth sign-in with Google, Apple, Microsoft, and Facebook, using provider-appropriate safeguards including PKCE where supported. Apple’s client secret is minted at runtime from its signing key rather than stored as a long-lived secret.
The whole thing ships as hardened Docker images, runs on Kubernetes, and fronts the internet through Cloudflare. Automated delivery runs through a self-hosted CI pipeline, and k6 exercises smoke, ramp, spike, and soak scenarios so capacity is measured rather than guessed.
Security by design
Built secure, not patched secure
Security was engineered in from the first commit — then independently reviewed against the codebase, with every significant finding remediated.
Operations
Run to production standards
A platform is only as good as the way it is operated. SouthpawStrings runs with the discipline of an enterprise service.
Documentation
Documented like it matters
Engineers love documentation — and businesses need it. An undocumented system is a liability: it can’t be audited, can’t be handed over, and depends entirely on whoever built it. So SouthpawStrings is documented the way a commercial system should be: every operational procedure is written down, versioned in git alongside the code, and kept current as the platform evolves.
That includes a deployment runbook, database safety procedures, setup guides for every external integration, the security review and its remediations, an architecture overview, and a formal engineering handover document — so another engineer could pick the platform up cold and run it.
That discipline isn’t project-specific. As-built documentation, runbooks anyone can follow, and a handover pack are how key-person risk gets removed from any system. If it isn’t documented, it isn’t finished.
Still moving
What’s been shipping lately
The platform is past 160 versioned releases and still ships in small, verified steps — each one with a changelog entry that records the decision behind it. August 2026 alone: the practice Desk’s window-manager core was extracted into @denley/desk-engine and re-adopted as a dependency; the desk gained OS-grade manners — an MRU window switcher, drag physics, edge snapping, directional keyboard focus, windows that arrive folded to exactly the content a player asked for; the phone experience got its own card stack; and the interface now carries four languages. Under the hood, the CI build host learned to clean up after itself as a written standard, because a full disk found in time is a rule, not an anecdote.
Much of that polish came from watching real use and refusing to ship a first draft of an interaction: the switcher was rebuilt after its first cut tested badly, snap previews were corrected to show exactly what a drop would do, and layout re-packs were taught to preserve the rows a player can see. The standard is simple — it has to feel right, not merely work.
How it was delivered
SouthpawStrings was built engineer-led and AI-accelerated: AI tooling was used to move faster on code, documentation, and testing — with a human engineer reviewing, constraining, and owning every decision. That is the same principle I apply to all professional work: AI as an accelerator, never a substitute for engineering judgement, security boundaries, or accountability.
Professional relevance
What this demonstrates
SouthpawStrings is a music project, not an IT business — but it is honest evidence of engineering discipline. If a guitarists’ resource hub warrants encrypted data, multi-factor authentication, zero-trust networking, and a disciplined release process, that says something about the standards applied: documentation, privacy, security, deployment automation, UX, and maintainability are treated as non-negotiable, even on a hobby project.
For commercial IT consulting, cloud, Microsoft 365, infrastructure, automation, or AI engineering work, please contact BTG and mention Andy Denley.