Showcase: this blog is published with Bailey

We have a rule on the team: if we wouldn’t publish it with Bailey, it’s not ready. The landing page, the docs, and now this blog all go online the exact way a creator’s site does. No special internal back door. If the path is good enough for us, it’s good enough to ship. If it isn’t, we feel the friction first.

So here’s the showcase: the page you’re reading right now.

How it gets here

This blog is a small static site — articles written in Markdown, built into plain HTML and CSS. When a new post is ready, it goes online through the same publishing loop anyone uses:

1. The site gets built into static files.
2. Those files go up to Bailey.
3. It’s live at its address. Done.

No server to babysit, no deploy pipeline to debug at midnight, no “why is the build red” mystery. The address stays the same; only the contents change.

What “dogfooding” actually buys us

Using your own product sounds like a virtue signal until it catches a real bug. A few things we only noticed because we publish this way:

• Friction is honest. If publishing an update is annoying for us, it’s annoying for everyone — and we fix it instead of routing around it with internal tooling.
• The address is the contract. Watching our own content live at a stable address, update after update, is what convinced us how much that stability matters. Your site’s URL should never change because you edited a sentence.
• Governance applies to us too. The same rules about bounded, declared, killable data apply to our pages. We don’t get an exemption, which means we feel the edges before you do.

The point

The best demo isn’t a video. It’s the thing being demonstrated, running in the open, doing its job. You’re looking at it.

Built something with your AI? This same path is one connection and one sentence away. Ask your assistant to put it online — and it’s live, at an address that’s yours.