Work

The Valencia Baryton Project is a touring chamber ensemble: four people, real money moving between them, and an operation held together by spreadsheets. We built the back office first — a role-based platform with a finance ledger tracking expenses from planned through reimbursed, a shared task board, a concert-program generator, and an append-only activity log that no role can edit or delete, the owner included.

The part that matters most is who doesn't see what. The ensemble's booking agent works in the system but reaches none of the finance pages — no page, no table, no export — because the agent's fee is one of the transactions, and a participant in a ledger shouldn't read the ledger. That separation is enforced by database policies written as a positive allowlist — not by application code — and the finance feature deliberately exposes no privileged function that could bypass them. Software at this size usually gets sharing right and separation wrong; this was designed around separation from the first migration.

The same platform prints the ensemble's concert programs — rendered by the browser's own print engine, no PDF library, no second layout engine to drift from the site's stylesheet. Each program sets its type density from a line count, so a work with movements costs the page what it should, fills the page rather than trailing off, and is never split across a page boundary; when a program genuinely needs a second sheet, the system says so instead of surprising anyone. The task board gives each person a column, sends email on assignment and completion, and keeps a timeline of every change. Every feature traces to a real complaint: the ledger began with a rental car settled between three people, the board because things were falling between four busy ones.

In front of it all sits the public site — video hero, cycling press quotes, a two-ground design system, and a full content admin so nothing needs a developer to change. The engagement shipped in three weeks — 41 database migrations in that span, none rolled back, no outages — at a fraction of the hours behind comparable agency builds, which are typically quoted at $25,000–70,000. And plainly, because it's why the domain understanding runs deep: our founder plays viola in the ensemble.

Congregations and small nonprofits run on software built decades ago, held together by spreadsheets and the one person who knows how the old system thinks. Stonebridge is that work brought into one connected platform: people and households, dues season and giving, invoices and statements a board can trust, a member portal where congregants keep their own details current, and a public website that reads the same records the office keeps.

The staff app is built in Flutter on a shared design system, keyboard-accessible throughout, in light and dark. Each organization's public website runs on Next.js — one deployment serving every organization under its own subdomain, with a public giving flow.

Every organization's data is isolated by row-level security enforced in the database, not the application; privileged actions are audited, and multi-factor authentication is required for every staff sign-in. Giving runs on Stripe Connect, so each organization's money settles into its own account and card data stays with Stripe, off the platform entirely.

The migration history rebuilds the whole database from nothing, the backup-restore procedure is rehearsed, and an incident runbook is written — because a platform that holds a community's records has to be able to prove it can recover them. The brand identity, marketing site, and published legal framework — terms, privacy, and a data processing agreement — were built alongside the product.

Every change ships through a reviewed pull request with recorded evidence; every schema change is rehearsed on a copy of production before it touches the real thing; security-relevant work gets an independent review before it lands. The process is how the product earns trust.

Paraggo's identity was built from the name up. The name is Greek in origin, and the brand rests on a single thesis — performance isn't created, it's accessed — carried in an aphoristic, stripped-down voice that deliberately refuses the hype register of the sports-psychology category. The typographic system does the work ornament usually does: numbered progressions, weight and italic contrast, and negative space that lets one thought land before the next arrives. It reads the same in a browser and in print, including a six-week instructor manual for the practice's ACCESS program.

The site itself is a full platform, not a brochure: a scrolling opening that stages the brand's core statements as the visitor descends, a private owner's area with password-free sign-in, secure file storage, built-in lesson booking, and a contact pipeline that lands in the inbox. Built on modern web technology and built to last — it looks and works right on every screen, for every visitor.

Beginning violinists learn notes and fingerings as two separate skills, then stall when they have to do both at once — mid-piece, at tempo. Violin Fingering Trainer closes that gap by making the pairing itself the game: match the note to the right finger and string, build speed through timed rounds, keep the streak alive.

Built in Flutter, so one codebase runs on phones and in the browser — designed for phones and tablets, playable anywhere. Structured so teachers can fold it into lessons and practice routines.