A dropped connection used to cost a typing indicator. With AI in the product, it costs an entire response, mid-generation. That single shift is enough to reopen a decision most teams made years ago and stopped thinking about: whether to keep building realtime infrastructure themselves, or buy it.
Fin, the AI agent platform formerly known as Intercom, made the call to buy. It had run its own realtime system, Nexus, for years, at the scale of one of the biggest support platforms on the internet. It reasoned its way to buying instead of building further.
Key takeaways
- Fin ran Nexus, its in-house realtime system, for years. It worked, until AI changed what the job required.
- Keeping a realtime system like Nexus running costs real money. Half of self-built realtime infrastructure runs $100K to $200K a year in upkeep, before engineering salaries.
- Don't pay to maintain a system just because it exists – keep it only if it actively helps you build a better product.
- For Fin, retiring Nexus produced 99.9999% reliability, 18M+ peak concurrent connections, and an 80% drop in HTTP GET requests.
AI conversations changed what realtime infrastructure has to do
Realtime infrastructure has always had one job: tell clients when something changed. A chat app pings the client when a new message arrives. A presence indicator flashes green when someone comes online. The client already has, or can quickly fetch, the actual content, so the realtime layer only ever needed to say "look now." Call this the signaling model. It's what almost every in-house realtime system was built for, Nexus included.
An AI conversation breaks that model. There's no separate content to fetch. The response doesn't exist until it's generated, token by token, and the realtime layer has to carry it directly: every token, in order, with no gaps, to whichever device the user is holding. That's a delivery model, not a signaling one, and it's a different job entirely. If your own system was built for the first job, this is probably the gap you're sitting on too.
It's the specific gap Ably AI Transport was built to close: a delivery layer designed for exactly this requirement – every token, in order, no gaps – rather than a signaling system stretched to act like one.
For Fin, that gap wasn't theoretical. Nexus was still signaling perfectly, still telling clients exactly when something changed. But when a connection dropped mid-generation, there was no partial message sitting somewhere to recover. The response itself was gone.
That's the specific failure Colin Kennedy, Principal Product Engineer at Fin, describes: "With AI, interactions are actually in realtime, as opposed to delayed responses from humans. Therefore realtime connections matter even more. A dropped connection can mean that users lose entire AI responses with detailed information. That's unacceptable."
Nexus was still doing exactly what it was built to do: signal changes reliably. What changed was the job around it. That distinction is what makes this an architecture decision rather than a fire to put out. Nothing was on fire. Everything still worked. It meant Fin could make the call deliberately, on its own timeline, instead of in a scramble.
In-house realtime upkeep runs $100K to $200K a year, before salaries
Even if you can bend your existing realtime infrastructure to handle AI agents and chat, the cost of keeping it running doesn't stay flat. It grows, and it grows faster the more AI-specific behavior gets bolted onto a system that wasn't built for it. None of that exists in a signaling-model system by default. Streaming has to become resumable, so a dropped connection doesn't cost the whole response. Tokens need strict ordering. A conversation has to survive a user switching from phone to laptop mid-response. Someone has to build all of it, on top of everything the system already does.
That's on top of a baseline that was already expensive before AI entered the picture. Half of self-built realtime infrastructure costs $100K to $200K a year to keep running, according to Ably's survey of over 500 engineering leaders. That figure is upkeep alone: cloud fees and operational overhead, before anyone's salary, and before a single engineer starts building the AI-specific layer on top.
The survey ran in 2022, and prices have only moved the wrong way since: Flexera's 2026 State of the Cloud report found wasted cloud spend climbed back up to 29% this year after five years of decline, with 17% of organizations blowing through their cloud budget entirely. Treat $100K to $200K as a floor, not a ceiling.
Teams reliably underestimate the bill going in: 93% of in-house builds needed four or more engineers, 52% needed more engineers than planned, 53% took longer than expected, and 65% of teams had an outage inside 18 months anyway.
Opportunity cost is what actually decides this
It shows up first at VP level, and it isn't unique to realtime. McKinsey's research on technical debt found CIOs report 10% to 20% of the budget meant for new products gets redirected to debt instead. One cloud provider CIO described cutting that tax from 75% of engineer time to 25% by managing it deliberately. DORA's 2025 research found the same pattern even among elite-performing engineering teams, who still spend most of their R&D time on maintenance rather than new capabilities. Fin and HubSpot hit the same arithmetic firsthand.
Max Freiert, Product Group Lead at HubSpot, faced the same call: "Around 20% of our engineering team is dedicated to infrastructure. But we could see that building realtime infrastructure we could rely on would be too complex and time-consuming to provide value for our customers. Overall, the opportunity cost associated with taking so many engineers away from core product innovation was simply too high."
HubSpot's version of that math: a 60% cut in upfront infrastructure costs and $300,000 a year saved since moving to Ably.
Every quarter your best engineers spend keeping a home-built realtime layer healthy is a quarter they don't spend on product, and that's before AI adds anything to the list. None of it requires Fin's scale to bite. The same arithmetic holds for a team of ten engineers deciding whether to keep patching a homegrown connection layer instead of shipping product.
AI makes "could" the wrong question to ask
Could you keep evolving your own realtime layer? Almost certainly, for as long as you're willing to keep patching it. AI doesn't make that harder to do. It makes it beside the point: the real question isn't whether your engineers can keep the system running – it's whether that's still the best use of them.
Fin already had an answer to that question, one built into how the company thinks about engineering effort: "We have a philosophy at Fin: run less software. Realtime infrastructure isn't our core competency. We'd rather invest engineering time in building better AI agents and customer experiences than maintaining websocket infrastructure."
This test belongs in your next architecture review. Colin puts it plainly: "Is maintaining this system helping you build a better product? If the answer is no – if you're spending time keeping the lights on instead of innovating – it's time to evaluate alternatives."
The question isn't "is it working?" – most in-house systems work – what matters is whether it's earning the engineering time it consumes.
How Ably supports complex migrations
Migrating off an existing realtime layer doesn't have to take as long as you'd expect. Doxy.me expected its full stack rebuild to take a year. It took under six months, with zero downtime, across 250,000+ patient visits a day. "It needed to be timed right, planned right, and implemented right," says Ben Anderson-Dukes, Vice President of Engineering at doxy.me. That discipline is what got a full rebuild done in half the time anyone expected.
Fin took a narrower version of the same approach: pilot one surface first, to confirm the integration wouldn't become another platform to maintain. Then move the single surface with the most to lose: Fin conversations, where a dropped connection does the most damage. It held, so Fin extended from there.
The lesson in both is the same: planned properly, a migration gets faster, not slower. Fin proved that one surface at a time. Doxy.me proved it by beating its own year-long estimate by half.
What buying gets you: reliability, scale, and the time to build your roadmap
The benefits of buying aren't hypothetical, and they're not unique to Fin. The same three things show up across customers: delivery reliability that holds under real load, scale you don't have to babysit, and the engineering time to actually build on the roadmap instead of propping up what's underneath it. Here's what that looked like for Fin.
Fin's published case study shows 99.9999% delivery reliability across workspaces, 18M+ peak concurrent connections, and 80% fewer HTTP GET requests once workaround-heavy patterns came out of the architecture.
The bigger win happens once you stop designing around gaps, and it isn't unique to Fin: "The biggest win isn't just that things work. It's that we trust the system. We're not designing around gaps anymore. We're building what we actually want to build," as Colin puts it.
"Designing around gaps" is the tax a realtime layer you don't fully trust puts on every roadmap conversation: features scoped down to what the infrastructure can survive. Move that layer to something you trust, the way Fin moved its AI conversations to Ably, and the tax disappears. The engineering time it was costing goes back into the roadmap. For Fin, that meant more investment in its AI Agent. You pay a vendor. You get the time to build it.
AI turns realtime delivery from a convenience into a requirement. Keeping that layer in-house runs $100K to $200K a year before salaries, and the opportunity cost is larger than the invoice. Fin ran a good in-house system for years and still concluded it wasn't worth keeping. The test isn't whether your system works. It's whether maintaining it is helping you build a better product.
Facing the same decision? Ably AI Transport is the most direct route to this delivery model — built specifically to carry AI responses token-by-token without losing them mid-generation. Check pricing or talk to an engineer about what an incremental migration looks like for your stack.
FAQ: build or buy for realtime infrastructure
Do AI agent experiences need custom realtime infrastructure, or does a managed provider work? Build only if realtime delivery is itself your differentiator and you can staff it permanently. For AI agent experiences the bar is higher than a working connection: resumable streams, guaranteed ordering, delivery across device switches, and fallback through enterprise proxies. Fin, operating at 18M+ peak concurrent connections, concluded that realtime infrastructure wasn't its core competency and moved to a managed layer. Most teams hit the same arithmetic at far smaller scale.
What does it cost to maintain in-house realtime infrastructure? In Ably's survey of over 500 engineering leaders, half of self-built realtime infrastructure cost $100K to $200K a year in upkeep, 93% of builds needed four or more engineers, and 52% needed more engineers than planned. The larger cost is opportunity: senior infrastructure engineers maintaining transport instead of shipping product. HubSpot estimated around 20% of its engineering team went to infrastructure before deciding the opportunity cost was too high.
When should you replace an in-house realtime system? Apply Fin's test: is maintaining the system helping you build a better product? Signals that the answer is no: AI features are blocked or scoped down because delivery can't be guaranteed, your team designs around known gaps rather than fixing them, and infrastructure upkeep consumes engineers you'd rather have on the roadmap. A system that still works can still fail this test.
What's the best way to add realtime delivery to an AI agent experience? Evaluate any option, including Ably, on delivery guarantees rather than feature lists: message ordering, exactly-once delivery, stream resumption after disconnection, protocol fallback for enterprise networks, and proven scale.
For AI agent experiences specifically, Ably AI Transport is purpose-built for that delivery layer between agents and users, and supports incremental adoption: you can migrate one high-impact surface first and expand from there.
