Every SaaS product eventually needs in app messaging. Onboarding tooltips, feature announcements, support chat, transactional notifications, user to user communication. The question is whether you should buy an off the shelf solution like Intercom or build something custom.
We have implemented both approaches across different projects. The answer depends on your stage, your use case, and how central messaging is to your product's value proposition. This post breaks down the real tradeoffs, not the marketing page version.
What Intercom Actually Gives You
Intercom is the default choice for in app messaging, and for good reason. Out of the box, you get:
- Live chat widget with agent routing and availability scheduling
- Product tours and onboarding flows with targeting rules
- In app notifications and banners triggered by user behavior
- Email campaigns tied to in app events
- Help center with article search integrated into the chat widget
- Bot flows for automated responses and qualification
- User segmentation based on attributes and behavior
The setup time is minimal. Drop a script tag or SDK into your app, configure your workspace, and you have a functioning support chat within an hour. For onboarding tours and targeted messages, the visual builder lets non engineers create and modify campaigns without code deployments.
This is genuinely powerful for early stage SaaS companies. You get a complete engagement platform without writing a single line of messaging infrastructure.
The Real Cost of Intercom
Intercom's pricing is where the calculus gets complicated. The published pricing starts at $39 per seat per month for the basic plan, but the features most SaaS companies need (product tours, custom bots, advanced targeting) are on higher tiers that start at $99 per seat per month.
The hidden costs add up quickly:
Per seat pricing scales with your team. At 10 support agents on the Pro plan, you are looking at roughly $12,000 per year. At 25 agents, $30,000. This is before add ons.
Resolution based pricing. Intercom introduced pricing tied to the number of AI resolved conversations. If you use their Fin AI agent, you pay per resolution on top of seat costs. For high volume support, this adds thousands per month.
Active user pricing on some plans. If your product has many active users who interact with Intercom features (chat, tours, notifications), costs scale with usage. A product with 50,000 monthly active users is in a different pricing universe than one with 5,000.
Data limits and integrations. Advanced data export, API rate limits, and certain integrations are gated to higher tiers. If you need your messaging data in your own analytics pipeline, expect to pay more.
For a funded SaaS company with 10 to 15 team members doing moderate volume support, the total Intercom bill typically lands between $20,000 and $50,000 per year. That is not unreasonable if it replaces building and maintaining the equivalent functionality in house. But it is also not cheap, and it compounds every year as your team and user base grow.
When Building Your Own Makes Sense
Building custom in app messaging makes sense in specific scenarios. If none of these apply to you, Intercom or a similar tool is probably the right call.
Messaging is your core product. If your SaaS is a collaboration tool, a customer communication platform, or anything where messaging is the primary value, you should own that infrastructure. Building on someone else's messaging system for your core feature creates a dependency that limits your product.
You need deep integration with your data model. Intercom knows about your users and their attributes. It does not know about your domain objects. If your messaging needs to be deeply contextual (referencing specific orders, projects, or records within your app), the integration work to pipe that context into Intercom can exceed the work of building a simpler custom solution.
You have already outgrown the cost curve. If your Intercom bill is above $40,000 per year and climbing, the math starts favoring a custom build for the subset of features you actually use. Most SaaS companies use about 30% of Intercom's feature set. Building that 30% custom can be cheaper than paying for 100%.
Regulatory or data residency requirements. Some industries require that customer communications stay within specific geographic boundaries or on infrastructure you control. Intercom is a US based SaaS product. If your compliance requirements prevent using it, custom is your only option.
Architecture for Custom In App Messaging
If you decide to build your own, here is the architecture we use on projects where custom messaging is the right call.
Real time transport layer. For live messaging, you need WebSockets or a real time subscription system. Supabase Realtime, Pusher, or Ably handle the transport layer without you building WebSocket infrastructure from scratch. We have written about the tradeoffs in our real time architecture guide. The transport layer handles connection management, reconnection, and message delivery. Your application handles message storage and business logic.
Message storage. Messages go in your database with a schema designed for fast retrieval. The core tables are:
- `conversations` (id, type, participants, metadata, created_at)
- `messages` (id, conversation_id, sender_id, content, type, read_at, created_at)
- `conversation_participants` (conversation_id, user_id, role, last_read_at)
Index on `conversation_id` and `created_at` for message retrieval. Index on `conversation_participants.user_id` for listing a user's conversations. This schema handles one on one support chat, group conversations, and system notifications with the same structure.
Notification system. In app notifications (the bell icon with a badge count) are separate from real time chat. These are simpler: a `notifications` table with user_id, type, title, body, read_at, and action_url. Query unread count for the badge. Mark as read on click. Push to the client via real time subscription when new notifications arrive.
Targeting and segmentation. If you need targeted in app messages (show this banner to users who signed up in the last 7 days and have not completed onboarding), build a simple rules engine. Define targeting rules as JSON conditions evaluated against user attributes. This does not need to be sophisticated. A basic condition evaluator covering equals, greater than, less than, contains, and boolean operators covers 90% of targeting use cases.
The build timeline. A functional custom in app messaging system with support chat, notifications, and basic targeting takes 4 to 8 weeks for an experienced team. That includes the backend, the frontend components, real time integration, and basic admin tools. It does not include product tours, email campaigns, or AI bot flows. Those are additional features that each add 2 to 4 weeks.
The Hybrid Approach
The approach we recommend most often is a hybrid. Use Intercom (or a similar tool) for support chat and knowledge base functionality. Build custom for in app notifications, feature announcements, and any messaging deeply tied to your product's data model.
This gives you:
- Professional support tooling without building agent dashboards, routing rules, and ticket management
- Full control over product specific messaging that needs deep data integration
- Lower Intercom costs because you are using fewer of their features
- No vendor lock in on the messaging that matters most to your product experience
The integration point is your user identity. When a user loads your app, Intercom's SDK initializes with their user ID and attributes for support chat. Your custom notification system initializes independently with the same user context. Both systems coexist in the UI without conflict.
Making the Decision
Here is the decision framework we use with clients:
Use Intercom if you are pre Series B, your team is under 10 people, messaging is not your core product, and your annual Intercom cost would be under $25,000. The time savings are worth it.
Build custom if messaging is your core product, your Intercom bill exceeds $40,000 per year, or you have strict data residency requirements.
Go hybrid if you need both solid support tooling and deep product integrated messaging. This is most SaaS companies at the growth stage.
The comparison between custom development and SaaS tools is a decision we help clients navigate regularly. The answer is rarely pure buy or pure build. It is about identifying which components are commodity (buy) and which are competitive advantage (build).
If you are evaluating your messaging architecture and want a clear recommendation for your specific situation, we do exactly this kind of consulting work. Get in touch and we will map out the right approach for your product and budget.