⋯ 76 unchanged lines
em.k { font-style: normal; color: var(--ink); font-weight: 600; }.sec-sub { font-size: 16px; color: var(--body); margin: -12px 0 24px; max-width: 46ch; }/* client-work gists */
.work { display: flex; flex-direction: column; gap: 30px; }.work .item h3 { font-size: 17.5px; font-weight: 600; letter-spacing: -0.015em; color: var(--ink); margin: 0 0 8px; }.work .item p { margin: 0; color: var(--body); }/* the figures — restrained, editorial, no card, no accent bar */
.figures { display: flex; flex-wrap: wrap; gap: 40px 56px; padding: 26px 0 30px; margin: 4px 0 26px; border-top: 1px solid var(--line); border-bottom: 1px solid var(--line); }.figures .fig { display: flex; flex-direction: column; gap: 7px; }⋯ 64 unchanged lines
<p class="lede">A client's AI music-video engine had outgrown its first codebase. Reverts were frequent and the mobile apps broke in ways nobody caught until users did.</p>
<p>We rebuilt it from Java to Python, contract-first and verified against the real mobile clients before a line shipped, then cut over in <em class="k">two weeks</em> with nothing rolled back. If your AI product has outgrown its first codebase and now costs you speed, that is the work we do.</p>
<p class="note">This quarter we shipped 116 updates to production. The team is now 20, up from 15.</p>
</section>
<section class="sec">
<h2>More client work</h2>
<div class="work">
<div class="item">
<h3>Evals that turned prompt changes from guesswork into a gate</h3>
<p>For a client's AI product, answer quality lived in a hand-edited system prompt and knowledge base, with no way to tell whether an edit made answers better or worse. You shipped it and watched. We built evals that run against the exact prompt, knowledge, and model recipe production uses, then made them a gate in the release pipeline. Now <em class="k">193</em> automated tests and <em class="k">2</em> release gates stand between a content change and users, and prompt changes ship through a pull request with a rendered diff instead of a silent database write.</p>
</div>
<div class="item">
<h3>Live whiteboard extraction, 50–60% faster</h3>
<p>A live whiteboard that consultants watch during client sessions was extracted section by section, so users stared at an empty board until the last one finished. We fanned the sections out into concurrent calls and streamed each in the moment it completed, so the wait tracks the slowest section instead of the sum of all of them, with the shared prompt prefix cache-marked so the added concurrency bills at cache-read prices. Latency fell <em class="k">50–60%</em>, behind two kill-switches and a never-regress guard so a partial publish can never blank a populated field.</p>
</div>
<div class="item">
<h3>Co-browsing a live whiteboard, with no account or install</h3>
<p>Showing a client a live whiteboard used to mean screen-sharing or exporting a file, and the first design only worked while everything ran on one machine. We now stream whiteboards over server-sent events as full-state snapshots: a REST call bootstraps the current state, SSE keeps it live, and Redis pub/sub carries changes across machines while Postgres stays the source of truth. Anyone can watch the real board update live, across any number of servers.</p>
</div>
</div>
</section>
<section class="sec">
⋯ 56 unchanged lines