From 319ce70bd785a543769d8ffb8862981e26bae059 Mon Sep 17 00:00:00 2001
From: Anthony Riera <19694603+Rieranthony@users.noreply.github.com>
Date: Sat, 14 Mar 2026 07:47:31 +0000
Subject: [PATCH 1/4] Add React support widget customization article
---
...to-customize-a-support-widget-in-react.mdx | 361 ++++++++++++++++++
1 file changed, 361 insertions(+)
create mode 100644 apps/web/content/blog/how-to-customize-a-support-widget-in-react.mdx
diff --git a/apps/web/content/blog/how-to-customize-a-support-widget-in-react.mdx b/apps/web/content/blog/how-to-customize-a-support-widget-in-react.mdx
new file mode 100644
index 00000000..99333b49
--- /dev/null
+++ b/apps/web/content/blog/how-to-customize-a-support-widget-in-react.mdx
@@ -0,0 +1,361 @@
+---
+title: "How to Customize a Support Widget in React"
+description: "Learn how to customize a support widget in React with Cossistant, from simple style overrides to custom triggers, custom content, and headless primitives."
+date: "2026-03-14"
+author: "Anthony Riera"
+tags: ["react", "support", "tutorial", "customization", "open-source"]
+image: "https://cdn.cossistant.com/landing/main-large.jpg"
+top: false
+related: []
+published: true
+---
+
+A lot of support widgets are easy to install.
+
+That part is not the problem.
+
+The problem starts when you want the widget to actually feel like *your* product.
+
+You want to change the chat bubble.
+You want to move the panel.
+You want the styles to match your app.
+You want the support experience in your navbar, your sidebar, or your own layout instead of some floating black box glued to the corner.
+
+That is where most tools get annoying.
+
+So let's do this properly.
+
+Here's how to customize a support widget in React with Cossistant, from simple styling all the way to fully composed, headless control.
+
+## Why customization matters
+
+For engineering-led teams, support is not just another plugin.
+
+It lives inside the product experience.
+
+If your app is polished and product-native everywhere else, but the support widget looks and behaves like a foreign object, users feel it immediately.
+
+That is why this matters.
+
+Not because customization is fun.
+Because support is part of the UX.
+
+## The real problem with most widgets
+
+Most support widgets stop being flexible right when things get interesting.
+
+You can usually:
+- change a color
+- upload a logo
+- maybe tweak a few labels
+
+But once you want real control — custom trigger, custom layout, custom interaction model, headless building blocks — the experience gets a lot worse.
+
+Cossistant is built differently.
+
+The docs are explicit about the model:
+- start with zero config
+- add styling
+- replace the trigger
+- control the content container
+- move to full composition
+- go headless with primitives if needed
+
+That is the right model for React teams.
+
+## 1. Start with style overrides
+
+If you do not need full control yet, start small.
+
+You can override widget styles with `classNames`:
+
+```tsx title="src/App.tsx"
+import { Support } from "@cossistant/react";
+
+export default function App() {
+ return (
+
+ );
+}
+```
+
+This is the fastest path when your goal is:
+- keep the default behavior
+- improve visual fit
+- avoid overengineering
+
+## 2. Change the position and behavior
+
+A lot of teams do not want the default placement.
+
+Cossistant lets you control:
+- side
+- alignment
+- offset
+- collision behavior
+- viewport padding
+
+```tsx title="src/App.tsx"
+import { Support } from "@cossistant/react";
+
+export default function App() {
+ return (
+
+ );
+}
+```
+
+That already gives you more real control than the usual "pick one of three canned layouts" approach.
+
+## 3. Replace the default chat bubble
+
+This is the customization point most people care about first.
+
+With `Support.Trigger`, you can replace the default floating trigger with your own button.
+
+```tsx title="src/App.tsx"
+import { Support, type TriggerRenderProps } from "@cossistant/react";
+
+export default function App() {
+ return (
+
+
+ {({ isOpen, unreadCount }: TriggerRenderProps) => (
+ <>
+ {isOpen ? "Close" : "Chat with us"}
+ {unreadCount > 0 && (
+
+ {unreadCount}
+
+ )}
+
+ )}
+
+
+ );
+}
+```
+
+This is already a big difference.
+
+You are not just repainting a vendor bubble.
+You are controlling the trigger itself.
+
+The render props also expose useful state:
+- `isOpen`
+- `unreadCount`
+- `isTyping`
+- `toggle`
+
+That means the trigger can behave like part of your app, not just like a sticker on top of it.
+
+## 4. Control the content container too
+
+If the trigger is not enough, move to `Support.Content`.
+
+This lets you control the support panel itself more directly:
+
+```tsx title="src/App.tsx"
+import { Support } from "@cossistant/react";
+
+export default function App() {
+ return (
+
+
+ {({ isOpen }) => {isOpen ? "Close" : "Help"}}
+
+
+
+
+
+ );
+}
+```
+
+At this point, the widget is not just styled.
+It is composed.
+
+That is a very different level of customization.
+
+## 5. Use full composition when the default shape is not enough
+
+If you want full control over how the pieces fit together, use `Support.Root`.
+
+```tsx title="src/App.tsx"
+import { Support } from "@cossistant/react";
+
+export default function App() {
+ return (
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+This is where the difference becomes obvious.
+
+A lot of widgets let you configure options.
+Cossistant lets you compose the experience in code.
+
+That is what real customization looks like.
+
+## 6. Go headless with primitives
+
+If you want complete control, use the `Primitives` API.
+
+The docs describe these primitives as:
+- headless
+- composable
+- developer-owned
+- inspired by shadcn/ui
+
+That gives you access to building blocks like:
+- `Primitives.Trigger`
+- `Primitives.Window`
+- `Primitives.Avatar`
+- `Primitives.ConversationTimeline`
+- `Primitives.MultimodalInput`
+
+Example:
+
+```tsx title="src/CustomWidget.tsx"
+import { Primitives } from "@cossistant/react";
+
+export function CustomWidget() {
+ return (
+ <>
+
+ {({ toggle, unreadCount }) => (
+
+ )}
+
+
+
+ {({ isOpen, close }) =>
+ isOpen && (
+
+
+
Custom support content
+
+ )
+ }
+
+
+ );
+}
+```
+
+This is not "change the accent color."
+This is: build the support experience the way your product needs it.
+
+## Why Cossistant is the right option if you actually care about customization
+
+Let’s say this cleanly.
+
+A lot of support tools are built to be configurable.
+Cossistant is built to be composable.
+
+That is the difference.
+
+Configurable means:
+- pick from settings
+- override some labels
+- tweak surface-level styling
+
+Composable means:
+- replace the trigger
+- control the content container
+- fully compose the widget tree
+- go headless when needed
+- build support into your actual product UI
+
+For teams that just want to drop in a support bubble and never touch it again, that difference may not matter.
+
+For React teams that care about product feel, it matters a lot.
+
+## A practical way to think about it
+
+Use the right level for the job:
+
+### Level 1
+Use `classNames` if you just want visual polish.
+
+### Level 2
+Use positioning props if placement matters.
+
+### Level 3
+Use `Support.Trigger` if you want your own chat bubble.
+
+### Level 4
+Use `Support.Content` or `Support.Root` if the widget layout needs to feel product-native.
+
+### Level 5
+Use `Primitives` if you want full control.
+
+That progression is one of the strongest things about the product.
+
+## Full customization ladder
+
+
+
+ Start with the default widget
+
+
+ Override styles with `classNames`
+
+
+ Reposition the widget with `side`, `align`, and `sideOffset`
+
+
+ Replace the default bubble with `Support.Trigger`
+
+
+ Control the panel with `Support.Content` or `Support.Root`
+
+
+ Move to `Primitives` when you want full headless control
+
+
+
+## Final thought
+
+If your idea of customization is "change the blue to purple," most support widgets will probably get you there.
+
+If your idea of customization is "make support feel like part of my product," that is a different category.
+
+That is where Cossistant gets interesting.
+
+It lets you start simple.
+Then it lets you keep going.
+
+That is the whole point.
+
+
From 9983cdafa80686b283000d625f256c7505838de6 Mon Sep 17 00:00:00 2001
From: Anthony Riera <19694603+Rieranthony@users.noreply.github.com>
Date: Sun, 15 Mar 2026 12:51:19 +0000
Subject: [PATCH 2/4] Add React-focused open source Intercom alternative
article
---
...e-intercom-alternative-for-react-teams.mdx | 250 ++++++++++++++++++
1 file changed, 250 insertions(+)
create mode 100644 apps/web/content/blog/open-source-intercom-alternative-for-react-teams.mdx
diff --git a/apps/web/content/blog/open-source-intercom-alternative-for-react-teams.mdx b/apps/web/content/blog/open-source-intercom-alternative-for-react-teams.mdx
new file mode 100644
index 00000000..a05b6179
--- /dev/null
+++ b/apps/web/content/blog/open-source-intercom-alternative-for-react-teams.mdx
@@ -0,0 +1,250 @@
+---
+title: "Open Source Intercom Alternative for React Teams"
+description: "If you're looking for an open-source Intercom alternative for a React app, here's what actually matters: control, composability, product-native UX, and a support experience that doesn't feel bolted on."
+date: "2026-03-15"
+author: "Anthony Riera"
+tags: ["react", "intercom", "open-source", "comparison", "support"]
+image: "https://cdn.cossistant.com/landing/main-large.jpg"
+top: false
+related: []
+published: true
+---
+
+If you're a React team looking for an open-source Intercom alternative, you're probably not just looking for "something cheaper."
+
+You're usually looking for one of these things:
+- more control
+- better product fit
+- less black-box behavior
+- a widget that does not look foreign inside your app
+- a support system that works for engineers, not just support ops
+
+That changes the conversation.
+
+Because once you look at support through that lens, a lot of alternatives stop looking that different.
+
+## The real problem with most Intercom alternatives
+
+Most alternatives solve the same category problem in roughly the same way.
+
+They give you:
+- a hosted widget
+- a dashboard
+- some automation
+- a set of settings and appearance options
+
+That is fine if your goal is to install support fast and never think about it again.
+
+But React teams usually want more than that.
+
+They want support to feel like part of the product.
+Not just something pasted on top of it.
+
+That is where the usual "Intercom alternative" list starts getting less useful.
+
+## What React teams actually care about
+
+If you're building a product in React, the bar is different.
+
+You care about:
+- whether the widget fits your UI system
+- whether you can replace the trigger
+- whether you can control layout and positioning
+- whether the support flow can evolve with your product
+- whether the implementation feels code-first instead of config-first
+
+That is why the right question is not just:
+
+> what is the best Intercom alternative?
+
+The better question is:
+
+> what is the best open-source Intercom alternative for a React team that wants control?
+
+## What to look for in an open-source Intercom alternative
+
+Here is the checklist that actually matters.
+
+### 1. Real React integration
+
+Not just a script tag with a React wrapper around it.
+
+A real React integration should feel native to your app.
+That means:
+- React package
+- provider setup that makes sense
+- component-based API
+- customization through code
+
+### 2. Product-native customization
+
+You should be able to do more than pick colors.
+
+The moment you want to:
+- replace the chat bubble
+- move the panel
+- control the content container
+- embed support into your app layout
+
+most black-box tools start fighting you.
+
+### 3. Progressive customization
+
+Good support tooling should let you start simple and go deeper later.
+
+That means:
+- default widget first
+- style overrides second
+- custom trigger third
+- deeper composition after that
+- headless control if needed
+
+### 4. Open-source posture that actually matters
+
+Open-source is not magic by itself.
+
+It matters when it gives you:
+- visibility
+- extensibility
+- less lock-in
+- more confidence in how the product works
+
+### 5. Built for engineering-led teams
+
+A lot of support products are built for teams that want to avoid touching code.
+
+That is not the same audience.
+
+If your team is engineering-led, you probably want support that behaves like part of the product surface, not part of a separate tooling empire.
+
+## Why this matters more in React than elsewhere
+
+React teams care more about composition than most teams.
+
+That is just reality.
+
+If your product uses component systems, design systems, shadcn-style thinking, and custom UX patterns, then a rigid support widget becomes obvious fast.
+
+You feel it immediately.
+
+A default bubble is fine for the first hour.
+After that, you start asking questions like:
+- can I replace this trigger?
+- can this live in the navbar?
+- can I control the panel?
+- can I build this into my own support surface later?
+
+That is where code-first support starts making sense.
+
+## Where Cossistant fits
+
+Cossistant is built around a code-first model.
+
+That means you can start with a basic widget, then progressively move into deeper customization.
+
+The documented path today looks like this:
+- start with ``
+- override styles with `classNames`
+- control placement with `side`, `align`, and `sideOffset`
+- replace the trigger with `Support.Trigger`
+- control the panel with `Support.Content`
+- use `Support.Root` for full composition
+- go headless with `Primitives` when you need deeper control
+
+That matters because the product is not only configurable.
+It is composable.
+
+For React teams, that is a big difference.
+
+## A practical example
+
+If you just want a support bubble, the default widget is enough.
+
+If you want your own trigger:
+
+```tsx title="src/App.tsx"
+import { Support, type TriggerRenderProps } from "@cossistant/react";
+
+export default function App() {
+ return (
+
+
+ {({ isOpen, unreadCount }: TriggerRenderProps) => (
+ <>
+ {isOpen ? "Close" : "Chat with us"}
+ {unreadCount > 0 && (
+
+ {unreadCount}
+
+ )}
+
+ )}
+
+
+ );
+}
+```
+
+And if that is still not enough, the support docs go further into `Support.Content`, `Support.Root`, and headless `Primitives`.
+
+That is the part React teams care about.
+
+## So is Cossistant the right Intercom alternative for every team?
+
+No.
+
+If a team just wants a polished hosted support platform with lots of settings and no appetite for product-level customization, there are plenty of tools in that lane.
+
+That is not the main wedge here.
+
+Cossistant is more interesting for teams that think like this:
+- we build in React or Next.js
+- we care how support feels inside the app
+- we want control
+- we do not want support to be a black box
+- we want a path from simple setup to deeper composition
+
+That is a narrower audience.
+But it is also a much sharper one.
+
+## The better way to frame the choice
+
+If you are comparing options, think about it like this.
+
+### Pick a traditional support platform if:
+- you want something mostly off-the-shelf
+- deep customization is not important
+- support is mostly a tooling problem for your team
+
+### Pick a code-first option if:
+- support is part of your product experience
+- your team cares about composability
+- React integration quality matters
+- you want a path from drop-in widget to custom support UX
+
+That is the real split.
+
+## Final thought
+
+The best open-source Intercom alternative for a React team is not the one with the longest feature checklist.
+
+It is the one that gives you the right control model.
+
+That is the difference.
+
+Not just "does it have chat?"
+But:
+- can it start simple?
+- can it evolve with the product?
+- can we make it feel like ours?
+
+That is where Cossistant makes sense.
+
+If you want the practical side next, start with:
+- [How to add a support widget to a React app](/blog/how-to-add-a-support-widget-to-a-react-app)
+- [How to customize a support widget in React](/blog/how-to-customize-a-support-widget-in-react)
+
+
From f0c09ce45b2dc90ff784ead4c4a890fd792f1c5d Mon Sep 17 00:00:00 2001
From: Anthony Riera <19694603+Rieranthony@users.noreply.github.com>
Date: Mon, 16 Mar 2026 02:54:53 +0000
Subject: [PATCH 3/4] Add open source Intercom alternatives article
---
...om-alternatives-for-technical-founders.mdx | 208 ++++++++++++++++++
1 file changed, 208 insertions(+)
create mode 100644 apps/web/content/blog/best-open-source-intercom-alternatives-for-technical-founders.mdx
diff --git a/apps/web/content/blog/best-open-source-intercom-alternatives-for-technical-founders.mdx b/apps/web/content/blog/best-open-source-intercom-alternatives-for-technical-founders.mdx
new file mode 100644
index 00000000..1e019020
--- /dev/null
+++ b/apps/web/content/blog/best-open-source-intercom-alternatives-for-technical-founders.mdx
@@ -0,0 +1,208 @@
+---
+title: "Best Open Source Intercom Alternatives for Technical Founders"
+description: "Looking for an open-source Intercom alternative? Here are the best options for technical founders, with a focus on control, composability, product fit, and developer-friendly support workflows."
+date: "2026-03-16"
+author: "Anthony Riera"
+tags: ["intercom", "open-source", "comparison", "founders", "support"]
+image: "https://cdn.cossistant.com/landing/main-large.jpg"
+top: false
+related: []
+published: true
+---
+
+If you're a technical founder looking for an open-source Intercom alternative, you are probably not optimizing for the same thing as everyone else.
+
+A generic buyer might ask:
+- does it have live chat?
+- does it have a dashboard?
+- does it have automation?
+
+A technical founder usually asks different questions:
+- can I control the product experience?
+- can I make support feel native inside my app?
+- can I extend it later?
+- can I avoid getting trapped inside a black-box tool?
+
+That is a different buying lens.
+
+So this list is built for that lens.
+
+## What technical founders should actually care about
+
+Before looking at tools, get the criteria right.
+
+If you are an engineering-led team, the real questions are usually:
+
+### 1. How much control do we have?
+
+Can you replace the trigger?
+Can you change layout and positioning?
+Can you make the support experience feel like part of your product?
+
+### 2. How code-first is the product?
+
+Is it just configurable?
+Or can you actually compose and extend it in code?
+
+### 3. Does open-source actually matter here?
+
+Open-source only matters if it gives you something useful:
+- less lock-in
+- more visibility
+- more extensibility
+- more confidence in how the product works
+
+### 4. Is it built for our kind of team?
+
+A lot of support tools are built for support operations teams.
+
+That is fine.
+But if you are a small technical team shipping product fast, the better fit may be a tool that treats support as part of the product surface.
+
+## The shortlist
+
+These are the strongest open-source Intercom alternatives for technical founders to look at first.
+
+## 1. Cossistant
+
+Best for:
+- React / Next.js teams
+- technical founders who want code-first control
+- teams that want support to feel product-native
+
+Why it stands out:
+- open-source
+- React and Next.js support is documented
+- support widget can start simple and then move into deeper customization
+- documented path from `` to `Support.Trigger`, `Support.Content`, `Support.Root`, and headless `Primitives`
+- strong fit for teams that care about composability, not just configuration
+
+Where it fits best:
+- small engineering-led SaaS teams
+- products where support UX matters
+- teams that want an open-source alternative to Intercom without giving up product control
+
+Where it is not the default fit:
+- teams that just want a fully off-the-shelf support suite and do not care about code-first customization
+
+## 2. Chatwoot
+
+Best for:
+- teams explicitly looking for open-source customer support / customer messaging
+- self-hosted/open-source buyers
+
+Why it matters:
+- one of the most visible open-source support platforms in this category
+- often appears in open-source Intercom alternative searches
+- strong relevance in self-hosted and open-source comparison conversations
+
+Where it fits best:
+- teams that care a lot about open-source posture and broader support platform needs
+
+## 3. Papercups
+
+Best for:
+- teams looking specifically for an open-source Intercom-style alternative
+- founders browsing the open-source chat/support layer of the market
+
+Why it matters:
+- strong mindshare around the phrase "open source Intercom alternative"
+- often shows up in the exact search space technical founders use
+
+Where it fits best:
+- teams starting from the "we want something Intercom-like but open-source" mindset
+
+## 4. Tiledesk
+
+Best for:
+- teams exploring open-source support and chatbot/helpdesk alternatives more broadly
+
+Why it matters:
+- appears in open-source Intercom alternative content
+- relevant when buyers are evaluating open support/chat tooling beyond the most obvious names
+
+Where it fits best:
+- teams that want to compare a wider range of open support options before choosing a direction
+
+## 5. Chatwoot + Papercups + Cossistant are not the same type of bet
+
+This matters.
+
+A lot of "best alternatives" articles flatten everything into one giant comparison table.
+That is lazy.
+
+These tools may all show up in the same open-source Intercom conversation, but the bet behind each one is different.
+
+A more useful way to think about them is:
+- **Chatwoot** = broader open-source support platform conversation
+- **Papercups** = open-source Intercom-style replacement conversation
+- **Cossistant** = code-first, product-native support for React / Next.js teams
+
+That distinction matters more than a fake checklist war.
+
+## The better way to choose
+
+### Pick a broader support-platform option if:
+- your main need is an open-source support stack
+- deeper product-native composition is not the primary concern
+- you care more about platform breadth than frontend control
+
+### Pick a code-first option if:
+- you are building in React or Next.js
+- you care how support feels inside the app
+- you want a path from default widget to deeper composition
+- you think of support as product UX, not just as a support inbox
+
+That is where Cossistant becomes interesting.
+
+## Why technical founders should be careful with generic alternatives lists
+
+Most alternatives content is written for broad traffic.
+
+That means it tends to optimize for:
+- long feature tables
+- generic pros/cons
+- weak audience targeting
+- easy comparison language
+
+That is not enough.
+
+Technical founders do not just need "the best tool."
+They need the right control model.
+
+That is why this category is better framed around:
+- composability
+- product fit
+- open-source posture
+- frontend ownership
+- extensibility
+
+Not just "does it have live chat?"
+
+## If your team is React-first, start here
+
+If you are React-first, the most useful next step is not another generic list.
+It is checking whether the product can actually support the way you want to build.
+
+Start with:
+- [Open source Intercom alternative for React teams](/blog/open-source-intercom-alternative-for-react-teams)
+- [How to add a support widget to a React app](/blog/how-to-add-a-support-widget-to-a-react-app)
+- [How to customize a support widget in React](/blog/how-to-customize-a-support-widget-in-react)
+
+That will tell you more than a giant comparison table ever will.
+
+## Final thought
+
+The best open-source Intercom alternative for technical founders is not just the most feature-rich tool in the category.
+
+It is the one that matches how your team actually builds.
+
+If your team wants a broader support platform, you will choose one kind of tool.
+If your team wants code-first control and product-native support, you will choose another.
+
+That is the split that matters.
+
+
From 114235dac887174293beb76f071a33b1c74c6570 Mon Sep 17 00:00:00 2001
From: Anthony Riera <19694603+Rieranthony@users.noreply.github.com>
Date: Mon, 16 Mar 2026 05:58:18 +0000
Subject: [PATCH 4/4] Fix article chain related links and cross-links
---
...en-source-intercom-alternatives-for-technical-founders.mdx | 4 +++-
.../blog/how-to-add-a-support-widget-to-a-nextjs-app.mdx | 2 +-
.../blog/how-to-add-a-support-widget-to-a-react-app.mdx | 2 +-
.../blog/how-to-customize-a-support-widget-in-react.mdx | 4 +++-
.../blog/open-source-intercom-alternative-for-react-teams.mdx | 4 +++-
5 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/apps/web/content/blog/best-open-source-intercom-alternatives-for-technical-founders.mdx b/apps/web/content/blog/best-open-source-intercom-alternatives-for-technical-founders.mdx
index 1e019020..a5f06435 100644
--- a/apps/web/content/blog/best-open-source-intercom-alternatives-for-technical-founders.mdx
+++ b/apps/web/content/blog/best-open-source-intercom-alternatives-for-technical-founders.mdx
@@ -6,7 +6,7 @@ author: "Anthony Riera"
tags: ["intercom", "open-source", "comparison", "founders", "support"]
image: "https://cdn.cossistant.com/landing/main-large.jpg"
top: false
-related: []
+related: ["open-source-intercom-alternative-for-react-teams", "how-to-add-a-support-widget-to-a-react-app", "how-to-customize-a-support-widget-in-react"]
published: true
---
@@ -27,6 +27,8 @@ That is a different buying lens.
So this list is built for that lens.
+If you already know you care about React-specific fit, start with [Open Source Intercom Alternative for React Teams](/blog/open-source-intercom-alternative-for-react-teams). This article is the broader founder-level view.
+
## What technical founders should actually care about
Before looking at tools, get the criteria right.
diff --git a/apps/web/content/blog/how-to-add-a-support-widget-to-a-nextjs-app.mdx b/apps/web/content/blog/how-to-add-a-support-widget-to-a-nextjs-app.mdx
index 2d1b88be..8af28bb1 100644
--- a/apps/web/content/blog/how-to-add-a-support-widget-to-a-nextjs-app.mdx
+++ b/apps/web/content/blog/how-to-add-a-support-widget-to-a-nextjs-app.mdx
@@ -6,7 +6,7 @@ author: "Anthony Riera"
tags: ["nextjs", "react", "support", "tutorial", "open-source"]
image: "https://cdn.cossistant.com/landing/main-large.jpg"
top: false
-related: []
+related: ["how-to-add-a-support-widget-to-a-react-app", "how-to-customize-a-support-widget-in-react"]
published: true
---
diff --git a/apps/web/content/blog/how-to-add-a-support-widget-to-a-react-app.mdx b/apps/web/content/blog/how-to-add-a-support-widget-to-a-react-app.mdx
index 6e72cba8..c8c48b2b 100644
--- a/apps/web/content/blog/how-to-add-a-support-widget-to-a-react-app.mdx
+++ b/apps/web/content/blog/how-to-add-a-support-widget-to-a-react-app.mdx
@@ -6,7 +6,7 @@ author: "Anthony Riera"
tags: ["react", "support", "tutorial", "open-source", "widget"]
image: "https://cdn.cossistant.com/landing/main-large.jpg"
top: false
-related: ["how-to-add-a-support-widget-to-a-nextjs-app"]
+related: ["how-to-add-a-support-widget-to-a-nextjs-app", "how-to-customize-a-support-widget-in-react", "open-source-intercom-alternative-for-react-teams"]
published: true
---
diff --git a/apps/web/content/blog/how-to-customize-a-support-widget-in-react.mdx b/apps/web/content/blog/how-to-customize-a-support-widget-in-react.mdx
index 99333b49..cd346d02 100644
--- a/apps/web/content/blog/how-to-customize-a-support-widget-in-react.mdx
+++ b/apps/web/content/blog/how-to-customize-a-support-widget-in-react.mdx
@@ -6,7 +6,7 @@ author: "Anthony Riera"
tags: ["react", "support", "tutorial", "customization", "open-source"]
image: "https://cdn.cossistant.com/landing/main-large.jpg"
top: false
-related: []
+related: ["how-to-add-a-support-widget-to-a-react-app", "open-source-intercom-alternative-for-react-teams", "best-open-source-intercom-alternatives-for-technical-founders"]
published: true
---
@@ -27,6 +27,8 @@ So let's do this properly.
Here's how to customize a support widget in React with Cossistant, from simple styling all the way to fully composed, headless control.
+If you have not installed the widget yet, start with [How to Add a Support Widget to a React App](/blog/how-to-add-a-support-widget-to-a-react-app).
+
## Why customization matters
For engineering-led teams, support is not just another plugin.
diff --git a/apps/web/content/blog/open-source-intercom-alternative-for-react-teams.mdx b/apps/web/content/blog/open-source-intercom-alternative-for-react-teams.mdx
index a05b6179..cde95c34 100644
--- a/apps/web/content/blog/open-source-intercom-alternative-for-react-teams.mdx
+++ b/apps/web/content/blog/open-source-intercom-alternative-for-react-teams.mdx
@@ -6,7 +6,7 @@ author: "Anthony Riera"
tags: ["react", "intercom", "open-source", "comparison", "support"]
image: "https://cdn.cossistant.com/landing/main-large.jpg"
top: false
-related: []
+related: ["how-to-add-a-support-widget-to-a-react-app", "how-to-customize-a-support-widget-in-react", "best-open-source-intercom-alternatives-for-technical-founders"]
published: true
---
@@ -23,6 +23,8 @@ That changes the conversation.
Because once you look at support through that lens, a lot of alternatives stop looking that different.
+If you want the practical setup first, start with [How to Add a Support Widget to a React App](/blog/how-to-add-a-support-widget-to-a-react-app). If you already have the widget running and want deeper control, go to [How to Customize a Support Widget in React](/blog/how-to-customize-a-support-widget-in-react).
+
## The real problem with most Intercom alternatives
Most alternatives solve the same category problem in roughly the same way.