Building in Someone Else's Domain

In late spring 2025 I took on a client — an elite bodybuilding coach with hundreds of thousands of followers and twenty years of domain expertise. He wanted to save time. His coaching knowledge was trapped in documents, FAQ threads, and his own head, and he was repeating himself constantly.

I suggested we start with a knowledge base. Not a product yet — a foundation. If we could extract, clean, and structure his life's work into something an AI could draw from, that brain would power everything else. Content. SEO. Internal tools. And eventually, if it made sense, a consumer product. But the knowledge base comes first because it forces you to understand the domain deeply before you build anything on top of it.

Living in the Material

I went through everything he had. Training protocols, nutrition frameworks, supplement guides, contest prep methodologies. Dense PDFs and Word docs with no consistent formatting. Years of FAQ exchanges with clients — coaching gold mixed in with personal details that couldn't be exposed.

The work was extraction and translation. Taking twenty years of expertise that lived in one person's head and scattered files and turning it into structured, retrievable knowledge. I built a pipeline that parsed his exchanges into clean question-answer pairs while stripping personal information. Not every document was worth keeping. Some material was outdated. Some contradicted other sources. Deciding what to include required understanding his philosophy well enough to know which answers represented his current thinking and which were artifacts of older methods.

This was with Sonnet 4.0. The extraction pipeline, the chunking decisions, the embedding strategy — all of that would be faster today with better models and longer context windows. But the judgment about what matters in someone else's domain doesn't compress. You can't shortcut reading the material and understanding how the pieces fit together.

By the time the knowledge base was solid, I understood his business. I could see where his value was concentrated and how his clients actually used his expertise. That understanding shaped every product decision that followed.

The Product

Three weeks in, the coach saw what the brain could do and asked me to turn it into a consumer-facing chatbot. I had reservations — I thought using the brain to scale his content and marketing would drive revenue faster with less overhead. But it was his business and his audience. I built what he wanted.

Full stack, solo. Streaming chat interface with tool calling and formatted responses. Auth. Stripe. A separate coach-client portal for private messaging and resource management. Shipped in 2.5 months from the start of the engagement. Over a hundred paying subscribers in the first month.

The UI work alone was a significant lift. Streaming responses need to feel as polished as ChatGPT or Claude — that's the baseline expectation now. Nutrition plans rendering as tables, program recommendations referencing specific protocols by name, the whole interface responsive and fast. You can't ship a chatbot that feels like a side project.

Guardrails as Product Design

The guardrail work deserves its own section because it's where most people underestimate the effort.

This is bodybuilding. The audience includes competitive athletes who use performance-enhancing drugs. They want specific, accurate information about compounds, dosing, and protocols — not a disclaimer that says "consult your doctor." If the AI refuses to engage with the topic, the product is worthless to the people who would actually pay for it. If it engages carelessly, someone gets hurt.

Every guardrail is a product decision. Which topics does the AI handle directly, which does it defer to the coach, which does it refuse entirely? How do you handle a question about drug interactions when the coach has twenty years of experience guiding athletes through exactly that — do you suppress his actual expertise because it's sensitive, or do you deliver it with appropriate context?

There's no universal answer. It depends on the audience, the domain, the liability, and the specific coach's philosophy. I tested extensively — adversarial prompts, edge cases, conversations that started innocently and escalated. Each round of testing surfaced new gaps. The guardrails weren't a config file I wrote once. They were an ongoing negotiation between being useful and being responsible, refined through dozens of iterations.

Tool design was the same kind of problem. We built a body composition calculator and program-specific tools so the agent felt congruent with the coach's existing courses and materials. Which tools to build, what inputs they need, when the agent should call them versus just answering from the knowledge base — these are product decisions that happen to be implemented as code.

What Stayed With Me

The knowledge base approach proved out. Starting with extraction and understanding before building the product meant every decision downstream was grounded in actual domain knowledge rather than assumptions. When I was making guardrail calls or designing tool behavior, I wasn't guessing about what the audience needed — I'd already read thousands of pages of their actual questions.

If I did this project again today, the code would take a third of the time. The models are better at parsing messy documents, following complex instructions, and handling tool calls. The streaming UI patterns are more established.

I'd still spend the same amount of time reading the material. I'd still spend the same amount of time on guardrails. I'd still start with the knowledge base before building anything else.