Why we dogfood FAQ Hub (and what eating our own dog food revealed about our UX)

After writing recently about why founders turn off AI support tools, a few people asked me how we test our own assumptions in practice.

The answer is simple: we dogfood FAQ Hub on FAQ Hub.

Our own help center, in-app Cmd+K search, and floating support widget are all powered completely by FAQ Hub.

Building a product to manage customer knowledge is one thing. Relying on it completely as a solo founder to handle real user queries is where you actually discover what works and what breaks.

Here are 3 key things dogfooding revealed to us:

1. The best documentation backlog comes from bot escalations
   Before using our own tool, updating documentation felt like guesswork. I would wonder what setup guide or API explanation to write next.

Once we enabled FAQ Hub on our own site, the secondary verification step started doing something unexpected. Whenever a user asked a question that was not covered in our CMS, the system declined to guess and routed the request to my Slack with full chat context.

That escalation transcript became our literal content backlog. Instead of guessing what users needed, every unresolved question showed us the exact article we needed to publish in the CMS next.

The Lesson: Escalation is not a failure of AI support. It is a direct signal showing you where your documentation is missing critical facts.

2. If editing your CMS is slow, your docs will decay
   When you build a support tool, it is easy to focus on flashy end-user UI like chat bubbles and smooth animations.

Using FAQ Hub daily forced me to focus heavily on the admin side. When I shipped a new feature or updated a workflow, I wanted to update our source of truth in under 30 seconds. If updating an article took five clicks and a slow page refresh, I caught myself delaying the update.

That realization led us to streamline the CMS editor, tag management, and draft publishing workflow.

The Lesson: Doc decay happens when the editor UI is tedious. Making article edits frictionless for the builder is just as important as the end-user chat experience.

3. Testing the handoff from the receiver's end
   It is easy to test if a chat widget looks nice on your frontend. It is much harder to realize how frustrating a handoff is until you are the person receiving the support notification on your phone.

By handling real incoming chats routed from FAQ Hub to Slack and email, we tested the exact context passed along with the ticket. Knowing the user's previous questions, the specific page they were viewing, and where the bot stopped gave me immediate context without asking them to repeat themselves.

The Lesson: You cannot evaluate handoff quality from the widget side alone. You have to experience what the support agent sees when taking over the conversation.

The Build-in-Public Takeaway
If you are building a product (especially in B2B or dev tools), dogfooding is not just a QA step. It is the fastest way to strip away vanity features and focus on what actually saves time.

How heavily do you use your own product in your day to day workflow? What was the most surprising bug or UX flaw your own team caught by dogfooding?