For months, cStar's support page at cstar.help/support ran on the same pre-built widgets we give every customer on day one. Search bar powered by our Library embed. Floating chat bubble in the corner. It worked. It was fine.

"Fine" is a word for frozen dinners and airport Wi-Fi. We build support software with boss battles and XP systems. "Fine" was never going to last.

We'd shipped a Headless SDK that lets developers create completely custom support experiences -- search, chat, ticket management, customer portals -- all through clean APIs and JavaScript. Our own support page looked like every other support page on the internet. A chef eating frozen dinners. A mechanic taking the bus. A Time Lord stuck in a phone booth that's just... a phone booth.

So we rebuilt it.

A Docs-Style 3-Column Layout

We ditched the marketing page with the hero section and the cards. Built a proper knowledge base app instead. Three panels matching our dashboard's golden ratio (1:1.618:1):

Left: Public Library sidebar with search and category navigation
Center: Article content with auto-generated table of contents
Right: Context panel -- TOC when reading, SDK showcase on the welcome page

The whole thing feels like part of the product, not a separate marketing page that someone forgot to update six months ago.

Live Stats from Our Own API

The welcome page shows real data pulled from the Library API at load time. 61 articles across 10 topics. Real-time view counts. Popular articles ranked by actual reads.

None of it hardcoded. Server-side rendered from the same API endpoints available to every cStar customer. When we add an article, the count updates. When an article gets popular, the ranking changes. It's alive.

const [categories, articles] = await Promise.all([
  fetch('https://cstar.help/api/library/YOUR_TEAM/categories').then(r => r.json()),
  fetch('https://cstar.help/api/library/YOUR_TEAM/articles?limit=100').then(r => r.json())
]);

Two API calls. No SDK required -- just REST. The stats calculate from the response.

A Chat Widget We Actually Wanted to Use

This is where it got interesting. Instead of dropping in our pre-built chat widget -- the default bubble, perfectly functional, seen it a thousand times -- we built a completely custom one using the CStarChat SDK:

3D arcade launcher matching our design system. Thick borders. Box shadows. The whole aesthetic.
Auth flow with signup/login, powered by our widget API endpoints.
Conversation management -- list, create, send messages. The works.
Smart deflection -- as you type your question, we search the knowledge base and suggest articles before you submit a ticket. Like the game hinting you should check the treasure chest before fighting the boss.

Single Svelte component. No iframe. Same DOM. Same styles. Powered by window.CStarChat methods.

// Start a conversation with context from the article they were reading
CStarChat.startConversation({
  subject: 'Help with webhooks',
  message: 'I was reading the webhook setup guide and need help.'
});

The Page Recognizes You

This part made me grin.

When a cStar customer visits our support page, the page recognizes them. The CStarChat SDK stores sessions in localStorage. On page load, we check for a stored session and personalize the welcome:

Welcome back, Josh!

No login required. No redirect. If you've used our chat widget before, we know who you are and can show your open conversations in the sidebar. It's the kind of small thing that's impossible with a generic help center -- it requires the SDK and the support page to share context, which they do, because they're both cStar.

Contextual Escalation

Every article has a "Was this helpful?" prompt at the bottom. Click "No" and we immediately surface a "Talk to our team" button that opens the chat widget pre-filled with the article they were reading.

The agent sees: "I was reading 'Setting Up Webhooks' and need help."

No context lost. No "what were you looking for?" back-and-forth. The customer typed nothing extra. The page did the work. Context preservation like a New Game+ carrying over your inventory.

SEO That Actually Works

Most support platforms render everything client-side. Google sees an empty page. A loading spinner indexed for eternity. Absolutely brutal.

Our Library API works server-side. Every article URL on our support page is server-rendered with full content, proper <title> tags, Open Graph metadata, and canonical URLs. When Google crawls /support/api-developer/javascript-sdk, it sees the complete article -- not a spinner.

// Server-side: fetch the article before the page renders
const res = await fetch('https://cstar.help/api/library/YOUR_TEAM/articles/javascript-sdk');
const { data: article } = await res.json();
// Now the HTML includes the full article content, title, meta tags

Works with any SSR framework -- SvelteKit, Next.js, Nuxt, Remix. The Library API is just REST. Call it from your server, render the HTML, ship it. Your support articles show up in Google with proper titles and descriptions instead of "Loading..."

What This Means for You

Everything we used to build this page is available to every cStar customer:

Library REST API -- Search articles, browse categories, get content
CStarChat JavaScript SDK -- Auth, conversations, messages, real-time events
Widget API Endpoints -- Signup, login, identity verification
Webhook Events -- Get notified when anything happens
Server-Side Compatible -- Works with any SSR framework for full SEO

You can build a custom support portal that matches your brand perfectly. An in-app help center with smart article suggestions. A customer self-service dashboard with conversation history. A completely custom chat experience -- no iframes, no constraints. An SEO-optimized knowledge base with server-rendered articles.

Or something we haven't imagined yet. That's the whole point of shipping tools instead of templates.

The Meta Part

The article "Building a Custom Support Portal" on our support page describes exactly how we built the support page that displays it.

We write guides about our SDK. We build our support page with our SDK. The page that teaches you how to use the tools is itself built with those tools.

That's not just dogfooding. That's the meal review, the restaurant review, and the cooking show -- all in one. It's turtles all the way down. It's recursion with a purpose. It's the support equivalent of a time loop where every iteration makes the timeline better.

We wouldn't ship tools we wouldn't use ourselves. Mess with the best, die like the rest -- except in this case, we are the best customer for our own product, and that keeps us honest.

Built with Bold Kindness by the cStar team. If you're building support software and not using it for your own support... maybe start there.

The cStar Blog

We Ate Our Own Dog Food (And It Was Delicious)

Ready to make support fun?