yk.camelcase.work

Recent Work

Recent products, built end to end. Each entry names the engineering decision that shaped it, not the feature list.

Every project below started from a real problem. From there the role is the same: product concept, system architecture, implementation, infrastructure, deployment and continuous delivery - each product keeps evolving well past its first release.

Mixtrace - Iterative mix diagnostics and verification

Mixtrace measures a rendered music mix, explains what is wrong in terms a mix engineer can act on inside a DAW, and checks on the next upload whether the fix actually worked. I built it around one loop - render, measure, diagnose, verify - where every finding carries a timecode, a centre frequency and a machine-readable success condition. All judgement is deterministic and rule-based: the same mix always gets the same diagnosis.

Problem

A mix goes through dozens of renders, and by the sixth one the engineer's ears no longer judge reliably - in a side-by-side comparison the louder version almost always wins. Meters report numbers, not what is wrong, where in the track, or what to change in the DAW. A week later, nobody remembers whether v7 actually fixed what v5 got wrong.

Signal analysisPython, NumPy, SciPyRule enginedeclarative versioned definitionsFix verificationper-diagnosis contractsCross-version alignmentdynamic time warpingMeasurement storagePostgreSQL, JSONB

Architecture

  • Split measurement from judgement. I normalise raw values into localised, target-free observations, then let rules name the problem. Because observations persist, switching genre or delivery target re-derives every diagnosis from storage - only an engine upgrade forces re-measuring audio.
  • Every finding carries a contract. Each diagnosis declares which metric must move, in which direction, and how much of the reported excess must go to count as fixed, plus guards on side effects. The next version is graded against it automatically.
  • Rules are data, not code. Diagnosis definitions are versioned declarative files loaded at startup, so thresholds and remedies change without a release. A linter refuses any rule whose remedy is vague or whose verification metric is absent from the measurement catalogue.
  • Versions are compared like for like. By ear the louder version almost always wins, so every comparison is loudness-matched first. Versions are then aligned automatically - by offset, section by section, or by dynamic time warping when a bar was added - so a finding at 1:42 in v5 is checked at the same musical moment in v7.
  • Real deviations get suppressed. Deltas below audibility, and anything inside measured genre variance, are reported as neutral observations rather than defects. When many rules fire at once I emit one profile-mismatch item - a tool that calls taste a defect is abandoned fast.

Editron

An API-first text transformation service. Its own web editor is a first-party client of the same public API and is forbidden from bypassing it, which is what keeps the integration surface honest; the processing engine is swappable behind one internal contract, with tenancy, API keys, quotas and usage accounting as first-class concerns, plus a published TypeScript SDK.

Lernklang

A gated listening platform for language learning with a school-facing analytics dashboard. One image, three roles: scheduled work runs as its own container, so restarting or scaling the web app never skips or double-runs a job - and configuration is validated at startup, the process refusing to boot on an invalid variable rather than failing quietly in production.

Herald

Topic-driven news collection, processing and delivery. Deduplication is enforced at delivery, keyed per channel by content hash with URL as fallback over a rolling window, so syndicated and live-updated articles are never sent twice; each article yields three independently produced formats, every one stamped with the exact pipeline version that made it, for reproducibility and cost accounting.

Smaller products and focused experiments are part of the same practice: they let an idea, an interaction pattern or a new workflow be validated quickly, before a larger system is committed to.