Not a demo, a product
There is a wide gap between an interesting LLM demo and a product people pay for. I work in that gap. Auth, billing, quotas, prompt versioning, guardrails, error states, and the unglamorous work of a real pricing page and onboarding flow.
The technical spine is usually Next.js on the frontend, Claude for reasoning and structured outputs, Supabase or MongoDB for state, and a lightweight prompt store so the product can improve without a full deploy.
Build vs buy, seriously
The most valuable thing I bring to an AI product conversation is a strong opinion about what not to build. Founders lose months on internal tools and infrastructure that already exists off the shelf. I have made those calls under my own name for my own products, and I bring the same discipline into client work.
Where this shows up in my own work
This pillar is not theoretical. I run live SaaS products of my own, including a browser extension builder platform and a workflow marketplace. Every design tradeoff on those products informs how I advise other founders on shipping AI features that survive contact with real users.
What does building an AI product involve beyond the LLM call?+
Auth, billing, quotas, prompt versioning, guardrails, error states, an honest pricing page, onboarding, and support tooling. The LLM call is often 5 percent of the work.
Which LLM should I build on?+
Claude for reasoning, long context work, and structured outputs. GPT 4 class models for wide integration and lower latency short prompts. The right answer depends on your product's failure cost more than benchmark scores.
How do you avoid vendor lock in on the model layer?+
Keep prompts, tools, and outputs in a thin abstraction so you can swap providers without rewriting product logic. Store prompt versions so you can A/B and roll back independently of the model.