Work  ·  Six systems

Systems I defined, built, integrated, and tested.

Each project below states what it is, what stage it is at, and what evidence exists. Nothing here is described as shipped, commercially available, or open source unless that status is explicitly stated.

  1. 01Emaki
  2. 02AskFrank
  3. 03Small’s Workshop
  4. 04Homelab Control
  5. 05Audiobook Studio
  6. 06PantrySink
01 Active development · Public product site live

Emaki

Private media infrastructure, made usable as one household product.

Role

Founder, product owner, systems designer, integration lead, tester

getemaki.com ↗
Emaki public product site

A public product surface for a private, self-hosted media system spanning server, web, device linking, and native Apple TV playback.

The problem

Self-hosted media systems are powerful and fragmented. A household ends up facing a pile of unrelated administration tools, inconsistent metadata, fragile downloads, and device-specific playback failures.

What I designed

One cohesive product over those capabilities: a secure control plane, household profiles, a React management interface, a native Apple TV client, real-time activity, media identity tracking, device linking, and public infrastructure.

What I did

Wrote the specifications, made the architectural calls, built and integrated the system against real services and hardware, reviewed the source, designed the validation gates, deployed the public site, and tested playback on actual Apple TV and home-theatre equipment.

What it demonstrates

Product ownership, complex integration, iterative debugging, infrastructure work, and turning a broad vision into testable subsystems.

Technical range

  • FastAPI
  • PostgreSQL
  • React
  • TypeScript
  • SwiftUI
  • tvOS
  • AVPlayer
  • Docker Compose
  • Cloudflare Workers & Pages
  • SSE
  • Encrypted credentials
  • DNS & deployment
Top
02 Active development · Public product site live

AskFrank

Fine-print clarity, with a privacy boundary the product refuses to cross.

Role

Product and technical lead

askfrank.app ↗
AskFrank public product site AskFrank app entry screen shown on the phone in the marketing page

Fine-print clarity presented as a focused product, with a local-first privacy boundary stated on the surface rather than buried in a policy.

The problem

People sign agreements across every part of their lives, but the promises, deadlines, obligations, and conflicts inside them are difficult to track.

What I designed

A local-first product that explains documents in plain language, remembers commitments, surfaces possible issues, answers grounded questions, and keeps raw files on the user’s device by default.

What I did

Defined the product boundary and privacy model, split local and server data responsibilities, designed the mobile/web/API architecture and analysis pipeline, and built across Expo, Next.js, SQLite, PostgreSQL, Docker, and Caddy.

What it demonstrates

Privacy-aware architecture, product restraint, document workflows, and the discipline to define what a product should not do.

Technical range

  • Expo
  • Next.js
  • SQLite
  • PostgreSQL
  • Docker
  • Caddy
  • On-device analysis boundary
  • Release gates
Top
03 Active development · Working engineering application

Small’s Workshop

Engineering software that has to prove its own math before you trust the answer.

Role

Product director and domain expert

Small’s Workshop validation suite

The engineering engine is checked against independently derivable references rather than trusting its own output.

The problem

Loudspeaker design tools tend to separate enclosure simulation, crossover work, measurement, cabinet design, and build documentation — or hide the engineering assumptions behind unexplained output.

What I designed

An offline-first engineering instrument that connects driver data through enclosure, crossover, cabinet, measurement, and build documentation while preserving units, assumptions, provenance, and revision history.

What I did

Supplied the domain model, formulas, workflows, acceptance criteria, audit strategy, source requirements, and UI behaviour — then built a validation methodology that checks the engine against references derived by hand.

16

verified topologies

131

hand-derived anchors

804

values held by the regression fence

What it demonstrates

Deep technical translation, numerical validation, measurement discipline, and product design for expert workflows.

Domain and technical range

  • Thiele/Small modelling
  • Sealed & vented alignments
  • Passive radiators
  • Excursion & port velocity
  • Crossover design
  • DSP export
  • Impedance extraction
  • Standing-wave analysis
  • Regression fences
  • Revision history
Top
04 Read-only MVP · Working, in progress

Homelab Control Interface

One read-only view across the whole infrastructure, with the dangerous parts deliberately switched off.

Role

Product definition, architecture, implementation, operations

Homelab Control Interface overview

A read-only command surface consolidates operational visibility: live status, alerts, node rollups, and system posture in one place.

The problem

Operational state for a real homelab is spread across a router UI, a hypervisor, a container host, storage tooling, and a handful of dashboards. Answering “is anything wrong?” means visiting all of them.

What I designed

A single surface unifying node, service, storage, network, AI/model, VM, activity, and operational views — with mutations explicitly out of scope for the MVP so that a read path can be trusted before a write path exists.

Current status

The screens above are the implemented read-only MVP running against real infrastructure. Write actions, remediation, and automation are not built. A separate set of visual-direction studies exists for the next stage and is not shown here as implementation.

Scope note

Read-only was a design decision, not a limitation to apologise for. An operations surface that can quietly break the network is worse than no surface at all, so the write path waits until the read path is proven.

What it demonstrates

Infrastructure literacy, operational judgment, scope discipline, and interface design for dense technical state.

Technical range

  • Linux
  • Docker
  • UniFi
  • VLANs
  • Tailscale
  • Storage roles
  • Model services
  • VM console
Top
05 Active development · Product and workflow prototype

Audiobook Studio

A production control plane for long-form narration.

Role

Product architect, workflow designer, technical director, validation lead

Audiobook Studio showing a chapter script table with speakers, emotion direction, render status, review queue, and the assembly timeline

One screen holds the manuscript, the casting, the performance direction, the render state of every line, the review queue, and the assembly timeline — so the relationship between script and finished audio never has to be reconstructed by hand.

The problem

Producing an audiobook involves far more than generating speech. Scripts must be divided into chapters and scenes, dialogue assigned to the correct performers, pronunciations standardised, pacing and emotion directed, failed lines regenerated, revisions tracked, and hundreds of audio segments assembled into consistent finished chapters. Existing workflows quickly become a mixture of documents, spreadsheets, provider dashboards, and manually named files.

What I designed

A unified production environment for that entire process. It organises source material into chapters, scenes, narration, and dialogue; maintains voice profiles and casting assignments; provides pronunciation and performance direction; coordinates individual and batch renders; and tracks every segment from source text through review, mastering, and final assembly.

My contribution

I defined the production model, information architecture, editing workflow, casting and voice-management concepts, render lifecycle, quality-control rules, review states, and mastering requirements. AI services assist with narration and implementation; the structure, constraints, acceptance criteria, and production decisions remain human-directed.

Problems are surfaced before they reach the audio

The review queue is a standing list of production faults, not a final listen-through.

  • Dialogue without a confirmed speaker
  • Characters without assigned voices
  • Missing emotion or pacing direction
  • Unusually long or difficult render segments
  • Stale audio after script revisions
  • Narration and dramatisation mismatches
  • Possible pronunciation issues
  • Missing, failed, or unreviewed renders

Audio review is measurable work

The system is designed to report the numbers a mastering engineer would ask for, rather than leaving quality to a subjective listen.

  • Loudness
  • True peak
  • Noise floor
  • Clipping
  • Dynamic range
  • Duration
  • Mastering state
  • Raw vs. processed delta
Why it matters

The goal is not to generate an AI voice. It is to make long-form audio production repeatable, reviewable, and resilient enough to carry an entire book without losing the relationship between the manuscript, the performance direction, the generated takes, the revisions, and the final mastered audio.

What it demonstrates

Complex workflow design, structured content modelling, batch-processing architecture, state management, audio engineering, and translating a professional production process into usable software.

Production model

  • Chapter and scene production model
  • Voice profiles and casting
  • Script-to-audio traceability
  • Batch rendering and review queues
  • Pronunciation and performance direction
  • Objective audio-quality validation
  • Revision-aware production states
  • Human-directed AI workflow
Top
06 Built, then shelved · Private project

PantrySink

Household coordination around food already on hand — and a decision to stop.

Role

Product and systems developer

PantrySink home screen showing tonight’s dinner, the week, and running-low items

The home screen answers one question first — what is for dinner tonight — and only then offers the week, the low-stock list, and a quick suggestion drawn from what is already in the house.

The problem

Grocery lists, pantry inventory, recipes, and meal plans get split across apps and across individual household members, so nobody has the whole picture at the moment they need it.

What I built

A shared household system covering pantry items, grocery planning, recipes, meals, participation, barcode lookup, and image-assisted product identification — with a cross-platform client, a private API, household-scoped access, Apple authentication, and live synchronisation.

Why it stopped

Partway in I found several existing products doing very nearly what I had built, so I stopped rather than keep spending on a solved problem. The system itself works, and it is here as evidence of the mobile, database, auth, and sync work — not as a product I am pursuing.

What it demonstrates

Consumer-product thinking, mobile systems, database modelling, authentication, real-time updates — and knowing when to stop.

Technical range

  • Cross-platform client
  • Private API
  • Household-scoped access
  • Apple authentication
  • Live sync
  • Barcode lookup
  • Image-assisted identification
Top

Talk about a technical problem.

View GitHub See how I work