Things I've built
Some of these are mine and some belong to clients. They're here because they're the ones I'm allowed to show — every one of them shipped, and every one is still running.
StoryKinder
A subscription service for interactive children's books — parents subscribe, kids read, and authors get paid automatically every month.
Underneath: an authoring studio, a portable story engine, Stripe Connect royalty distribution, and children's data handled to COPPA standard.
Three modules in one system: an authoring studio for writers, a reader-facing library, and a portable story engine with no app-specific dependencies — so it can be wrapped in a native shell later without a rewrite. Content is data, never hardcoded.
Children's data shaped the schema. Kids never authenticate. Parents own the account, hold verifiable consent, and can review, export, revoke, or delete everything behind a PIN. COPPA was a design input, not a checkbox at the end.
Money that isn't mine. Author royalties are a completion-weighted pool paid out over Stripe Connect. That sits close enough to money transmission that I wrote an architecture decision record, invariant tests, and a build guard that fails CI if banned vocabulary enters the payment code.
Security tested as code. Privilege escalation, server-action authorization, storage isolation, and review race conditions are covered by a database-level test harness that runs on every commit.
Made from the same parts
Named the way I keep them ready-built. The first four are in every build; the rest are what this one needed. All of them existed before the project did, which is the whole reason it did not start from nothing.
- Foundation
- Audit trails
- Built-in help
- Website
- Roles & permissions
- Payments
- Recurring billing
- Customer records
- Documents & signatures
- Photos & files
- Email notifications
- Reports & dashboards
1/4The reader-facing front page — original art per book, and the vocabulary support built into the reading that is the parent-facing pitch.
TradePals
Certification-prep and field-reference apps for skilled trades — fiber, electrical, welding, plumbing, wind, pools, elevators. Eight apps, one shared engine, so each new trade ships in weeks.
Underneath: subscription renewal cycles tied to credential recertification dates, offline-first field reference, shared auth and billing across the portfolio.
Fiber, electrical, welding, plumbing, wind, pools, elevators — each app on its own subdomain, each led by the credential its users actually search for rather than by the technology inside it.
The interesting engineering problem isn't any single app. It's building one platform where a new trade launches without a new codebase, and structuring acquisition so a free public practice exam converts into a subscription. Certifications renew on a cycle, which is what makes the retention math work.
Made from the same parts
Named the way I keep them ready-built. The first four are in every build; the rest are what this one needed. All of them existed before the project did, which is the whole reason it did not start from nothing.
- Foundation
- Audit trails
- Built-in help
- Website
- Roles & permissions
- Payments
- Recurring billing
- Customer records
- Email notifications
- Works with no signal
- Reports & dashboards
Texas Seraphim
A pro basketball franchise with no digital presence at all. Phase 0: a site that converts, email capture, and an authenticated subscriber dashboard — built so schedules, stats, media, and sponsor inventory drop in later without a rebuild.
Underneath: staged architecture, auth from day one, phase boundaries defined before a line was written.
The alternative was a form that emailed submissions into an inbox. Phase 0 shipped instead as a scoped, dated deliverable: landing page, email capture, and an authenticated subscriber dashboard the owner can actually use.
The architecture underneath anticipates the phases the client wants next — schedules, standings and stats, media, community, sponsors — so growth means building on top rather than starting over. Scope was written down first, including what explicitly wasn't in Phase 0.
Made from the same parts
Named the way I keep them ready-built. The first four are in every build; the rest are what this one needed. All of them existed before the project did, which is the whole reason it did not start from nothing.
- Foundation
- Audit trails
- Built-in help
- Website
- Roles & permissions
- Customer portal
- Customer records
- Email notifications
Vengig
A marketplace connecting musicians, venues, and fans — with a recording studio built into the browser.
Underneath: three-sided marketplace mechanics, musician-to-musician network density before venue onboarding, city-by-city launch sequencing.
Three-sided marketplaces die of cold start. The design answer here is to make the supply side valuable to itself first: musicians join to find other musicians and record together, which builds density before a single venue is onboarded.
Venue booking and the fan discovery app layer on once a market is dense enough to be worth selling into. Growth runs city by city rather than nationally, because liquidity is local.
Made from the same parts
Named the way I keep them ready-built. The first four are in every build; the rest are what this one needed. All of them existed before the project did, which is the whole reason it did not start from nothing.
- Foundation
- Audit trails
- Built-in help
- Website
- Roles & permissions
- Customer portal
- Payments
- Online booking
- Reviews & referrals
- Customer records
- In-app messaging
- Reports & dashboards
1/4The way in — email, Google or X, with Turnstile in front of it. One credential carries across the artist, venue and fan apps.
Don't see your kind of business here?
You probably won't. Most of what I build never becomes a website — the scheduling board a contractor uses every morning doesn't have a landing page. If you want to know whether I've done something like yours, just ask.