Building an In-App Support Inbox Instead of Buying Intercom

Every SaaS founder eventually looks at their Intercom bill and asks whether they should just build the support inbox themselves. Sometimes the answer is yes. Building a customer support inbox for SaaS is a lot less work than the vendors want you to believe — and a lot more work than a weekend hackathon suggests.

Here's how we scope this conversation when a founder brings it up.

When building actually makes sense

Three signals push toward build:

• Support is a differentiator, not a cost center (developer tools, high-touch B2B, healthcare).
• Your product already has real-time infrastructure you can reuse.
• You need deep product integration — showing the user's account state, recent actions, or in-app context — and the vendor's iframe embed feels clunky.

Two signals push toward buy:

• You need multichannel (email, WhatsApp, SMS) from day one.
• You have a support team of more than two people who will hate a homegrown tool.

The mistake teams make

They build a chat widget, ship it, and call it done. Then a customer replies to an email, the reply doesn't thread, and support spends an hour digging through Slack looking for context.

The chat widget is 20% of the work. The other 80% is conversation state, agent routing, notification plumbing, and search.

What to build first

1. A conversation model that isn't tied to a channel

A conversation belongs to a customer and has messages. A message has a source (in-app, email, imported). Every channel adds messages to the same conversation. If you get this wrong, every future integration is painful.

2. In-app widget with unread state

A drawer, not a modal. Persistent unread counter, message list, composer. Server-sent events or WebSockets for delivery — polling works too at small scale and is worth it for the operational simplicity.

3. Agent side, in the same app

Agents live in your admin. They see the same conversation the customer sees, plus a context sidebar with the customer's account, plan, recent activity, and open issues.

This context is the reason to build. No vendor gives you the full richness of your own data model without a fragile Zapier chain.

4. Email in and out

Inbound: a catch-all address routes to your API via Postmark, Resend, or SES. The subject line references the conversation ID. Outbound: replies go from a support address with the same reference.

This is where teams get stuck. Reply threading is fiddly. Budget a week just for this.

5. Notifications

Customers get emailed when they're offline and an agent replies. Agents get pinged in Slack or the app when a new conversation arrives. Nothing exotic — reliable delivery is the whole game.

What you can skip at the start

• Multi-agent assignment logic. Round-robin with a manual override handles ten agents.
• SLAs and business hours. Ship without them until a customer asks.
• Canned responses UI. Text expander apps do this outside your product for free.
• Bot flows. If you're going to add AI, start with reply suggestions, not autonomous replies.

Where the trap doors are

Email deliverability. If your outbound mail lands in spam, the whole system falls apart. Use a dedicated subdomain, warm it slowly, and set up SPF, DKIM, and DMARC before day one. Related reading: Transactional email for SaaS.

Attachment handling. Screenshots pasted into chat need object storage, virus scanning if you're serious, and thumbnails.

Search across conversations. At 500 conversations, users can scroll. At 50,000, they need real search. Retrofit is painful.

Adding AI without embarrassing yourself

Two safe wins:

• Draft-reply generation for agents. Model reads the conversation and drafts a response. Agent edits and sends. Big time savings, low risk.
• Automatic triage. Model tags conversations by category and urgency. Feeds into routing.

What we avoid on day one: autonomous replies to customers. The reputational downside on a wrong answer is higher than the labor saved. Related reading: Reducing hallucinations in production.

Trade-offs to be honest about

Building costs 4-8 weeks for a solid v1, plus ongoing maintenance. Intercom-class vendors charge $500-$5000/month depending on features and volume. The math flips at different revenue levels for different companies — do the actual comparison before deciding.

Common misconceptions

"We'll just embed the chat widget from a vendor and skin it." The embed gets you 30% there and gives you none of the deep product integration that made you consider buying vs. building.

"Real-time is required." For most B2B, no. Users check email. Agents check the queue. Replies within an hour are fine.

"It's just a table with messages." The table is easy. The routing, threading, notifications, and email plumbing are the actual work.

FAQ

What database schema do I start with?

Three tables: conversations, messages, participants. Everything else is polish on top.

Do I need WebSockets?

Not on day one. Polling every 5 seconds while a conversation is open feels real-time enough. Move to a socket layer when it's cheap enough (Supabase Realtime, Ably, Pusher).

How do I handle unauthenticated support?

Sign a short-lived token identifying the visitor, store it in localStorage, and let them come back to the same conversation on reload. Merge into the user record on signup.

Where to go from here

If you're weighing build vs. buy for support, the honest math is easier once someone has done this before. Our SaaS and web apps team has shipped exactly this feature more than once — happy to trade notes.