Why I Built My Own AI Helpdesk Instead of Paying for One

Every SaaS website needs a support chat. A visitor lands on your pricing page, has a question, and if there is no one to answer it in that moment, they leave. The conversion dies in silence.

The obvious solution is Intercom. Or Zendesk. Or Crisp, Drift, HelpScout, Tidio -- there are dozens of options, all priced between $29 and $99 per month per seat. For a solo founder running six products from Abidjan, the math does not work. That is $174 to $594 per year for a chat widget on one marketing site.

But pricing was not the real reason I built my own. The real reason is that I already had everything I needed.

The Infrastructure Was Already There

sh0.dev has an AI assistant. It powers the dashboard chat -- connected to the user's server via MCP, with access to 25 tools for managing deployments, apps, databases, backups. It also has a docs mode for the marketing site: a simpler assistant that searches documentation, looks up API endpoints, and generates configuration files.

The docs mode is exactly what a helpdesk needs. A visitor asks "How much does sh0 cost?" -- the AI has the pricing data in its system prompt. A visitor asks "How do I deploy a Next.js app?" -- the AI searches the documentation and returns a step-by-step guide with links.

The streaming infrastructure was built. The SSE format was defined. The tool execution pipeline was tested. The billing system tracked tokens. All I needed was a public endpoint that skipped authentication and a floating widget that consumed the stream.

That is a few hours of work. Not a $50/month subscription.

The Decision Framework

I have a rule for build-vs-buy decisions: if the marginal cost of building is lower than one month of the subscription, build it. The ongoing cost is then zero (or near-zero), and you own the feature forever.

Here is the actual cost breakdown:

The runtime cost is what makes this viable at scale. Haiku 4.5 costs $1.20 per million input tokens and $6.00 per million output tokens (with our 20% margin). A typical helpdesk conversation uses about 2,000 input tokens and 500 output tokens. That is $0.0024 for the input and $0.003 for the output. Call it $0.005 per exchange. Most visitors ask 1-2 questions.

At 1,000 conversations per month -- far more than a new product gets -- the total cost is $5. Intercom charges $29/month for that same volume, with no AI that actually knows your product.

What the AI Knows That Intercom Does Not

This is the part that changes the economics entirely. A traditional helpdesk requires one of two things:

1. A human agent who knows the product (expensive, not available 24/7)
2. A chatbot trained on your docs (requires separate training, maintenance, and a third-party AI provider)

The sh0 helpdesk AI does not need either. It already has a 4,000-word system prompt that contains:

• Every sh0 feature and capability
• The full documentation navigation structure
• The complete pricing table
• CLI command reference
• API endpoint reference (searchable via tool)
• Links to every documentation page

When a visitor asks "Can sh0 deploy a Django app?", the AI does not guess. It calls search_docs("deploy django"), finds the relevant documentation page, and responds with a concise answer and a link. When a visitor asks "What is the difference between Pro and Business?", it reads the pricing overview from its own prompt and gives a clear comparison.

This is not a generic chatbot. It is the same AI that architectured the product, explaining the product it built.

The Architecture in 30 Seconds

Visitor types in widget
    |
    v
POST /api/ai/helpdesk (no auth, rate-limited)
    |
    v
buildHelpdeskPrompt() = buildDocsPrompt() + chat persona overlay
    |
    v
Anthropic API (Haiku 4.5, streaming)
Tools: search_docs, get_api_reference, suggest_actions, web_search
    |
    v
SSE stream -> widget renders markdown in real-time
    |
    v
Save messages to PostgreSQL, deduct tokens from site owner's wallet

The widget is a single Svelte 5 component. 490 lines. Floating button in the bottom-right corner, expands to a 380x520px chat panel. Markdown rendering via marked with DOMPurify sanitization. localStorage persistence for session continuity. Suggestion chips after every response.

The admin dashboard shows every conversation: visitor info, full transcript, token usage, estimated cost. Status management (open, resolved, spam) with one click.

What I Did Not Build

Equally important is what I deliberately left out:

• No email collection form. The visitor can optionally provide their name and email, but it is not a gate. Friction kills the one thing helpdesk chat exists for: answering the question right now.
• No human handoff. If the AI cannot answer, it suggests emailing [email protected]. I am a solo founder -- I do not have agents waiting in a queue.
• No chatbot personality. The system prompt says "be warm, concise, and conversational." It does not say "be fun" or "use emojis" or "have a name." The AI is a support agent, not a character.
• No analytics dashboard. The admin page shows conversations and costs. I do not need funnel analysis or sentiment scoring. I need to know what visitors are asking and whether the AI answered correctly.

Every feature I did not build is a feature I do not maintain.

The Security Story

A public, unauthenticated AI endpoint on a marketing website is a surface that needs hardening. Three layers of protection:

Rate limiting: 30 messages per 10 minutes per session. 60 per 10 minutes per IP. 5 new conversations per hour per IP. In-memory, not Redis -- acceptable for the traffic volume of a new product.

Input validation: Messages capped at 2,000 characters. Session IDs capped at 100 characters. Visitor name, email, and page URL truncated to sane limits. Conversations capped at 200 messages total.

Billing protection: Balance check before every API call. If the site owner's wallet is empty, the helpdesk returns "temporarily unavailable" -- it does not keep streaming and accumulate negative balance.

The two audit rounds found two Critical issues that I missed:

1. XSS via {@html}: The widget rendered AI-generated markdown without sanitization. A prompt injection attack could make the AI output <img onerror="...">. Fixed with DOMPurify.
2. No balance check: The endpoint called deductTokens() after streaming but never checked balance before. Fixed by adding checkBalance() before the API call.

Both were obvious in hindsight. Both were invisible during implementation. This is why the multi-session audit methodology exists.

The Real Advantage

The helpdesk widget went from plan to production in one session, with two audit sessions following. Nine files changed. Migration applied. Build passes.

But the real advantage is not speed. It is that the AI support agent will never give a wrong answer about sh0's pricing, never tell a visitor that sh0 supports a feature it does not, and never go offline because a SaaS vendor changed their API.

The knowledge lives in the system prompt. When I add a feature to sh0, I update the documentation. The helpdesk AI reads the documentation. The knowledge propagates automatically.

No training pipeline. No fine-tuning. No manual FAQ updates. Just a system prompt that stays in sync with the product it describes.

That is worth more than any $50/month widget.

Next in the series: From Docs Chatbot to Live Support Agent -- The technical architecture: how we turned an existing AI docs assistant into a public helpdesk with 9 files and zero new dependencies.