Why we dogfood
We are building a developer-first messaging platform — closer to Customer.io than a sales CRM. That means our own site is customer zero.
Every feature we ship for instrumentation, segments, and flows should run on our stack first. Dogfooding is not a marketing line for us; it is how we find the rough edges before other developers do.
What we instrument
The marketing app loads @zerohuman/sdk/browser via a thin BrowserAnalytics wrapper. When VITE_ZEROHUMAN_PUBLISHABLE_KEY is set, every route change sends a PageView with device and UTM context.
When a builder signs in, we call identify() with their email and name so web activity merges onto the same customer record as server-side events later.
Revenue events stay server-side with a secret key — Purchase and amounts never ship from the browser bundle.
How we use MCP
Campaign work starts in the IDE. We connect the Zero Human MCP server in Cursor or Claude Code, OAuth in once, then describe flows in plain English — activation drips, win-back branches, multi-channel sends.
The agent reads live events and segments instead of guessing schema. Human operators use the same inbox and flow UI when they need to edit copy or approve sends.
What we are learning
The biggest gap dogfooding surfaces is time-to-first-flow: tracking is fast, but a great MCP prompt still beats clicking through UI for the second and third campaigns.
We publish this story as the first entry in our builder stories — not because we have dozens of logos, but because the best proof at our stage is showing exactly how we use the product we sell.
