Letting customers use a product by saying what they want

The problem

Every click, filter and form in a product is effort, and effort is where customers give up. Yak lets them describe what they want instead: upgrade to annual billing, find last month's order, change a booking. It answers questions, guides people to the right page, and completes the action for them inside the product.

The hard part isn't the conversation. It's doing real things in someone else's product, safely, without them rebuilding anything. Yak gets a business AI integration on its site in minutes, with no backend data piping: it uses the APIs the site already has, so there's no data to export, sync or duplicate.

Constraints

• Nothing to rebuild. Yak has to work with the UI, APIs, authentication, permissions and business logic a product already has.
• The AI only sees what the user can. Every action has to run as the signed-in user, inside the product's existing access controls, not through a privileged back door.
• Low risk to try. A business should be able to evaluate it properly before committing. Because Yak runs on the APIs the site already has, a team can install it in a non-production environment and try it against real flows without touching production data.
• Every framework. It has to drop into whatever the product is built with, front end and API layer alike.
• Voice and text do the same things. Realtime voice runs over WebRTC with its own session model; chat is request and response. Both have to reach the same actions.
• Solo engineer. A founding team of three, with me as the only engineer.

What shaped it

The insight. Front ends are now dominated by a handful of frameworks, and data access by a handful of patterns: Next.js, React, Vue and their peers on one side, tRPC, GraphQL and REST/OpenAPI on the other. When every stack was different, a product like this meant custom integration work for every customer. Now a set of SDKs for the major frameworks, plus adapters for the common data access patterns, reaches a large share of modern products. That made a drop-in, no-piping integration a viable thing to build.

The turning point. Yak started as a chat box, like most AI on websites. A sales meeting changed that. It led us towards being an experience on the page itself, led by realtime voice: talking to the product while it responds around you, rather than typing into a box in the corner. Voice became a first-class way in, and the focus moved from answering in a chat window to guiding people through the page and acting on it.

Buy, not build. Wiring a model to an API is within reach of most engineering teams, so Yak had to be worth buying instead. The demo is the easy part. Around it sits everything that turns an AI feature into something a business can trust and run: access controls, governance, analytics and insights, compliance, quality, and managing models as they change. Each is a project in its own right, and none of them is ever finished. Yak takes that work on, so a team gets the whole surrounding system rather than another thing to maintain.

What I did

I founded Yak, and it became a co-founded company as the founding team grew to three. I built the whole platform myself as the sole engineer.

• Integrating with the app's own API layer. Rather than asking businesses to build a separate set of AI tools, Yak plugs into the API layer their front end already uses. Adapters for tRPC, GraphQL and REST/OpenAPI turn existing procedures and endpoints into actions, and an allowlist decides which ones the assistant may call.
• Running in the product's auth. Tool calls execute on the customer's own server, through a handler mounted in their app, with the original request. Their existing session and access checks apply automatically, so the assistant can only do what that user could.
• Knowing the product. Yak learns the app's pages so it can navigate people to the right place, reads the current page for context, and refreshes the interface when it changes data, so the product and the conversation stay in sync.
• Realtime voice. A voice mode over the OpenAI Realtime API, using WebRTC with ephemeral per-session auth. Voice tool calls flow through the same handlers as chat, so a business integrates once.
• Knowledge and external tools. Knowledge bases and external tools connect over MCP (Model Context Protocol, an open standard for connecting AI to tools), with an OAuth connect flow and encrypted token storage, and power both chat and voice.
• The platform around it. SDKs for Next.js, React, Vue, Svelte, Nuxt, Angular and plain JavaScript, alongside the API adapters, built in a pnpm and Turborepo monorepo with enforced layering, and run on AWS through CDK.

Architecture

The line between the two is the point. Yak runs the conversation: the models, realtime voice, governance, analytics and knowledge. When the conversation needs to do something, the Yak SDK on the page sends the call to a handler inside the customer's own app, which runs it on their API layer exactly as it would any request from that signed-in user. Yak never holds keys to the customer's product, and their data stays in their systems unless an answer needs it. When the data changes, the interface refreshes to match.

Outcome

• In production with a paying customer.
• A complete platform, from framework SDKs and API adapters to voice and infrastructure, that I built and run myself.