<- back

how yaps came together

within 21 hours of the foundation commit, yaps had a web app, an iPhone app, a real-time backend, and an audio worker. the useful part of that story is not that agents wrote code quickly. it is how many finished pieces were available before yaps had a name—and how the work was directed around them.

the product idea was new: friends talk in live rooms while an ambient agent helps turn parts of the conversation into things worth keeping. the surrounding requirements were familiar. the app still needed sign-in, data, web and native foundations, model and media tools, testing, observability, and a release path.

those familiar parts already existed as managed services, shared packages, app foundations, and agent-facing tools. yaps was composed from them, then made specific through its room model, ambient-agent behavior, artifact feed, and interfaces.

what already existed

some capabilities are bought. Vercel, Convex, and Cloudflare cover hosting, data, networking, and storage. LiveKit and Deepgram handle live audio and transcription. model, search, and media providers add other product abilities. Doppler, Sentry, Axiom, PostHog, and Braintrust handle secrets, errors, logs, usage, and evaluations.

other capabilities are code that has already survived real products. yaps pulled from 25 shared web, backend, and tooling packages plus nine shared Swift packages. a stripped version of Keris supplied a known repository shape, sign-in, tests, developer access, and release wiring. multiple Claude and Codex subscriptions supplied enough capacity to work on several bounded parts at once.

# how the pieces meet
bought capabilitieshosting · data · live audio · transcription · models
reusable parts25 web/backend/tooling packages · 9 Swift packages
known foundationapp shell · auth · tests · agent tools · release paths
new for yapsproduct decisions
  • channels and rooms
  • ambient-agent behavior
  • artifact feed and sharing
  • web and iPhone interactions
one product
webiPhonebackendaudio worker

the reused pieces sit below the interface. the local layer is where yaps becomes its own product.

the subscriptions and services are inputs, not the system. the compounding work is deciding how each service is used, wrapping stable behavior in tested packages, keeping foundations current, and giving agents reliable ways to start, inspect, test, and release an app.

what reuse looked like in practice

# reused / built for yaps / reason
  1. foundation + authreused: app shell · sign-in · dev access · tests · deploysbuilt for yaps: yaps data model · product UIreason: skip standard setup
  2. agent stackreused: runs · evals · memory · search · media · logsbuilt for yaps: attention policy · output rulesreason: share execution, keep behavior local
  3. web + iPhonereused: auth · backend contracts · design · observabilitybuilt for yaps: native room · feed · navigationreason: share seams, not interfaces

1. begin from a known app shape

the first yaps commit was not an empty repository. it was a lean copy of Keris with Keris-specific product code removed and the useful foundation left in place. 34 minutes later the channel, room, transcript, and artifact data model landed. 11 minutes after that, the first yaps web surfaces landed. reuse removed standard setup; it did not supply the product model or interface.

2. share capabilities, not behavior

the backend reused building blocks for agent runs, evaluations, memory, search, media generation, storage, authentication, and observability. yaps still decided when the ambient agent should help, when it should stay quiet, what belongs in a room, and how an output should retain its connection to the conversation. shared packages handled execution; yaps supplied the product meaning.

3. reuse the seams between surfaces

the iPhone app reused Swift packages for authentication, startup, data connectivity, agent UI, design, developer access, observability, and proof tooling. the web app used the same backend contracts and the same families of auth, design, testing, and observability tools. identity, data, errors, and releases stayed predictable while each interface could still be designed for its actual device.

bespoke work still matters

live audio is a useful counterexample. LiveKit provided the room and audio infrastructure, and Deepgram provided transcription. yaps still needed its own worker, room lifecycle, participant mapping, backend integration, agent context, and web and iPhone room experiences. buying a managed service removed the need to build an audio network; it did not turn audio into this product.

the practical line is simple: reuse a component when its contract stays the same across products. keep work inside the app when it expresses the product's own rules, timing, or feel. if that work later repeats with a stable shape, promote it into a shared package or foundation then—not before.

directing the build

the first prompt set the premise, the donor app, the web-first order, and the quality bar. it did not attempt to describe every screen. a 20-question interview then resolved decisions with large downstream consequences: whether live rooms were the centerpiece, what a channel contained, when the agent should speak, which outputs belonged in the first version, what was public, and what had to be real on day one.

# one decision at a time
humanagents
  1. 01directionoutcome + references
  2. 02questioncontext + real choices
  3. 03decisionchoose · reject · add color
  4. 04build + proofbounded work + checks
  5. 05real usebrowser · iPhone · production

the next prompt comes from the state of the product, not from an empty prompt bar.

this continued after the opening interview. across the main build thread, the agent paused for 88 structured question rounds containing 146 individual questions. a useful question arrived with context and actual choices: choose a room model, ratify an audio path, decide an emission rhythm, or react to the interface already on screen. that is more effective than asking someone to invent the next prompt from nothing.

one main Claude conversation kept the whole product in view and acted like a producer. it turned decisions into bounded briefs for focused agents working on the web app, iPhone app, backend, audio, agent behavior, authentication, sharing, releases, and review. the archive contains 104 such briefs and 60 structured results. each useful brief named the outcome, the surface, the constraints, how to prove the work, and whether it could ship.

the human part stayed at product altitude: provide references, make decisions, try the real browser and iPhone app, and reject weak results. when an awkward agent reply was being hidden with brittle filtering, that direction was rejected; the better fix was to improve the instructions, context, tools, and interface that produced the reply. agents owned the code and tests. human feedback shaped the product they were serving.

what happened across five days

the first production deployment existed 3 hours and 11 minutes after the foundation commit. through august 11, the main branch accumulated 346 commits and Vercel recorded 305 deployment attempts. 257 became ready; 48 ended in error and fed the next correction. the more useful context is what those iterations connected.

# the opening build · aug 7–11, 2026
4connected product surfaces
34shared packages
346commits
305deployments
  1. 58 commits
    the product takes shape
    • a stripped Keris foundation lands first
    • the yaps data model follows 34 minutes later; web surfaces follow 11 minutes after that
    • rooms, auth, the landing page, and the first production deployment are exercised the same evening
  2. 133 commits
    iPhone and live audio join the system
    • the native login-to-home spine and room interface connect to the shared backend
    • a silent room worker sends per-speaker audio to transcription
    • agent outputs, sharing, room persistence, and web/native details move through rapid product review
  3. 73 commits
    the loops become real
    • TestFlight builds 12 and 13 put the native app into an installable release loop
    • observability, public artifact sharing, room reliability, and agent behavior are tightened
    • production-room audits turn live conversations into concrete fixes
  4. 49 commits
    the surfaces converge
    • yap becomes yaps across the wordmark, copy, links, and legal surfaces
    • production auth, native content parity, and durable artifact delivery are reconciled
    • a real agent-silence incident is traced to an overly strict contract and repaired
  5. 33 commits
    public, useful, and still moving
    • within-room memory and web notifications arrive
    • search, navigation, loading states, and native room behavior converge
    • the ambient agent cadence is recalibrated from use in actual rooms

these numbers are not a universal productivity score. they describe a short feedback loop across four surfaces. shared code reduced the amount of standard work. frequent deployments exposed integration problems. focused agents kept corrections bounded. direct use on web, iPhone, and live rooms supplied the final product feedback.

as of august 11, the web app is live at yaps.talk, and the web app, iPhone app, backend, and audio worker operate as one product. yaps came together quickly because standard capabilities were already reusable, product decisions were made when they mattered, and every surface could be tested while it was being composed.