A production engine, rebuilt in two weeks.

The quarter in one read: proof we ship fast, and a few things worth keeping whether or not you ever hire us.

The rebuild

2 weeksJava → Python rebuild, start to cutover

0rollbacks after launch

~50%less code, larger API surface

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.

We rebuilt it from Java to Python, contract-first and verified against the real mobile clients before a line shipped, then cut over in two weeks with nothing rolled back. If your AI product has outgrown its first codebase and now costs you speed, that is the work we do.

This quarter we shipped 116 updates to production. The team is now 20, up from 15.

More client work

Evals that turned prompt changes from guesswork into a gate

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 193 automated tests and 2 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.

Live whiteboard extraction, 50–60% faster

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 50–60%, behind two kill-switches and a never-regress guard so a partial publish can never blank a populated field.

Co-browsing a live whiteboard, with no account or install

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.

Worth reading

Prompt caching, and how to think about itWhere caching saves real money and latency with large models, and where it quietly does not. → The metrics we judge AI output byHow we measure whether a model's output is good, and keep our evals honest as the product changes. → How we run a big migration without regretThe questions we answer before a rewrite, so it ships in weeks instead of stalling for a year. →

What we make

Products that are born out of our AI-first workflows.

StenoMeeting notes that write themselves, clean and searchable when the call ends.steno.unravel.tech ↗ thingShip your coding agents' output as live, commentable, versioned pages. This letter runs on it.usething.ai ↗ TabloA tiny companion that watches your AI coding agents from a corner of the screen.tablo.unravel.tech ↗

Weighing a rebuild?

Thirty minutes, and we'll tell you straight whether it's worth doing, what it would take, and how fast we could do it.

Book a call or reply to this email — it reaches us directly at kapil@unravel.tech