1
00:00:00,000 --> 00:00:04,000
Welcome back to the Deep Dive. Today, we're tackling something that sounds maybe a

2
00:00:04,000 --> 00:00:07,440
bit complex on the surface, real time communication.

3
00:00:07,440 --> 00:00:12,690
Right. Think instant chat, live document editing, those stock tickers that just

4
00:00:12,690 --> 00:00:13,080
move.

5
00:00:13,080 --> 00:00:18,280
Exactly. Stuff that feels essential now, but when it breaks, the whole experience

6
00:00:18,280 --> 00:00:19,320
just crumbles.

7
00:00:19,320 --> 00:00:20,640
Yeah, it really does.

8
00:00:20,640 --> 00:00:24,890
So we've got some great source material here focused on any cable, which is a

9
00:00:24,890 --> 00:00:29,560
dedicated real time server. And this dive is really for you, the learner.

10
00:00:29,720 --> 00:00:30,960
We want to give you a shortcut.

11
00:00:30,960 --> 00:00:35,210
A shortcut to understanding why reliable real time is actually quite hard to build

12
00:00:35,210 --> 00:00:35,680
yourself.

13
00:00:35,680 --> 00:00:40,720
And more importantly, how a system like AnyCable makes it, well, dramatically

14
00:00:40,720 --> 00:00:42,880
easier and crucially more reliable.

15
00:00:42,880 --> 00:00:43,840
It's dot on.

16
00:00:43,840 --> 00:00:47,480
Before we get into the weeds, though, a quick shout out to the supporter making

17
00:00:47,480 --> 00:00:49,920
this deep dive possible. Safe Server.

18
00:00:49,920 --> 00:00:53,790
Yeah, huge thanks to them. They help with hosting exactly this kind of powerful

19
00:00:53,790 --> 00:00:54,320
software.

20
00:00:54,320 --> 00:00:57,510
And they support digital transformation efforts generally help to get those

21
00:00:57,510 --> 00:00:59,320
ambitious projects running smoothly.

22
00:00:59,360 --> 00:01:02,390
Definitely check them out. You can learn more about their hosting and digital

23
00:01:02,390 --> 00:01:05,320
support at www.safeserver.de.

24
00:01:05,320 --> 00:01:09,280
That's www.safeserver.de.

25
00:01:09,280 --> 00:01:11,000
All right, let's dive in.

26
00:01:11,000 --> 00:01:13,920
Okay, so our mission today, absolute clarity for you.

27
00:01:13,920 --> 00:01:19,090
The source material zeros in on how AnyCable delivers guaranteed reliable two way

28
00:01:19,090 --> 00:01:20,360
communication.

29
00:01:20,360 --> 00:01:22,560
So the goal isn't just knowing it's reliable.

30
00:01:22,560 --> 00:01:27,330
No, it's understanding the how the mechanism behind it and how that tackles the big

31
00:01:27,330 --> 00:01:28,520
headaches like, you know, dropped

32
00:01:28,520 --> 00:01:30,280
messages and scaling up.

33
00:01:30,280 --> 00:01:35,000
Got it. And looking at the sources, what jumps out is flexibility.

34
00:01:35,000 --> 00:01:38,240
AnyCable isn't locked into one way of doing things.

35
00:01:38,240 --> 00:01:42,120
Not at all. There's an open source version, a managed source option software as a

36
00:01:42,120 --> 00:01:44,040
service and an on-premise pro

37
00:01:44,040 --> 00:01:44,520
version.

38
00:01:44,520 --> 00:01:47,880
And it works well with the big players like Rails, JavaScript, TypeScript.

39
00:01:47,880 --> 00:01:52,120
But honestly, the sources say it integrates with pretty much any backend system you

40
00:01:52,120 --> 00:01:52,680
might have.

41
00:01:52,680 --> 00:01:54,360
Okay, let's establish the baseline then.

42
00:01:54,360 --> 00:01:56,000
What do we mean by real time?

43
00:01:56,000 --> 00:01:58,160
We're talking low latency interaction.

44
00:01:58,240 --> 00:02:00,440
Things happening ideally within milliseconds.

45
00:02:00,440 --> 00:02:02,720
The usual tool developers reach for is WebSockets.

46
00:02:02,720 --> 00:02:05,440
Right. Those persistent connections between the browser and the server.

47
00:02:05,440 --> 00:02:12,000
Exactly. But the fundamental issue with many basic WebSockets setups is, well, they're

48
00:02:12,000 --> 00:02:12,520
fragile.

49
00:02:12,520 --> 00:02:14,440
They often lack delivery guarantees.

50
00:02:14,440 --> 00:02:18,520
Meaning, if your internet connection hiccups for even a second.

51
00:02:18,520 --> 00:02:21,560
And let's be honest, that happens all the time, especially on mobile.

52
00:02:21,560 --> 00:02:22,720
Oh, yeah. All the time.

53
00:02:22,720 --> 00:02:27,320
Those messages sent during the blip, usually they're just lost, gone forever.

54
00:02:27,360 --> 00:02:28,800
And that's the core pain point.

55
00:02:28,800 --> 00:02:30,640
Any cable is built to solve, right?

56
00:02:30,640 --> 00:02:31,920
That reliability gap.

57
00:02:31,920 --> 00:02:37,220
Precisely. It's engineered to automatically recover messages missed during those

58
00:02:37,220 --> 00:02:37,600
tiny

59
00:02:37,600 --> 00:02:40,320
connection drops, the ones you barely notice on Wi-Fi even.

60
00:02:40,320 --> 00:02:43,400
And also the longer ones, like if you go into a tunnel or an elevator.

61
00:02:43,400 --> 00:02:48,160
Yeah, those two. It handles both micro interruptions and more significant outages.

62
00:02:48,160 --> 00:02:49,520
OK, but how does it do that?

63
00:02:49,520 --> 00:02:51,360
What's the mechanism the source has mentioned?

64
00:02:51,360 --> 00:02:55,150
So instead of just letting the connection die and hoping for the best when it comes

65
00:02:55,150 --> 00:02:56,000
back, any

66
00:02:56,000 --> 00:02:58,840
cable buffers messages on the server side.

67
00:02:58,840 --> 00:03:00,760
Buffers them, like hold on to them.

68
00:03:00,760 --> 00:03:04,640
Exactly. And it uses unique sequence identifiers for every message.

69
00:03:04,640 --> 00:03:06,880
Think of them like numbered packages being sent.

70
00:03:06,880 --> 00:03:08,800
OK, package number one, package number two.

71
00:03:08,800 --> 00:03:12,310
Right. So when your connection comes back online, maybe after that elevator ride,

72
00:03:12,310 --> 00:03:12,400
the

73
00:03:12,400 --> 00:03:15,040
client says, hey, the last package I got was number 10.

74
00:03:15,040 --> 00:03:16,160
Then the server knows.

75
00:03:16,160 --> 00:03:20,760
The server knows to send packages 11, 12, 13 and so on in the correct order.

76
00:03:20,760 --> 00:03:22,560
Everything you missed is restored.

77
00:03:22,760 --> 00:03:28,600
Ah, OK. So it effectively guarantees delivery without me, the developer, having to

78
00:03:28,600 --> 00:03:28,840
write

79
00:03:28,840 --> 00:03:32,600
tons of complex code to handle disconnections and retries.

80
00:03:32,600 --> 00:03:34,280
That's the core value proposition.

81
00:03:34,280 --> 00:03:37,440
It solves that specific real time problem so you don't have to.

82
00:03:37,440 --> 00:03:41,600
The sources even mention an emulation showing how it handles failures and restores

83
00:03:41,600 --> 00:03:42,200
messages.

84
00:03:42,200 --> 00:03:43,800
That sounds incredibly useful.

85
00:03:43,800 --> 00:03:45,880
But I have to ask, is there a trade off?

86
00:03:45,880 --> 00:03:51,000
Does adding this layer of guaranteed delivery and buffering impact performance or

87
00:03:51,000 --> 00:03:51,200
add

88
00:03:51,200 --> 00:03:56,160
complexity compared to just using a basic, maybe less reliable WebSocket library?

89
00:03:56,160 --> 00:03:57,520
That's a fair question.

90
00:03:57,520 --> 00:04:02,800
The sources indicate that, yes, compared to a completely raw, no guarantees WebSocket

91
00:04:02,800 --> 00:04:04,520
connection, there's a slight overhead.

92
00:04:04,520 --> 00:04:06,560
But any cable is built in Go.

93
00:04:06,560 --> 00:04:08,800
Which is known for being pretty fast and efficient.

94
00:04:08,800 --> 00:04:11,400
Extremely efficient, especially with memory.

95
00:04:11,400 --> 00:04:14,240
The pro version is even more optimized in that regard.

96
00:04:14,240 --> 00:04:16,480
So the trade off is really quite small.

97
00:04:16,480 --> 00:04:20,360
You accept a tiny bit more system complexity upfront.

98
00:04:20,360 --> 00:04:25,560
In exchange for not having to build and maintain that complex reliability logic

99
00:04:25,560 --> 00:04:26,000
yourself.

100
00:04:26,000 --> 00:04:26,720
Exactly.

101
00:04:26,720 --> 00:04:31,210
And you gain reliability that's been battle tested in large scale apps for over

102
00:04:31,210 --> 00:04:31,640
seven

103
00:04:31,640 --> 00:04:33,160
years, according to the sources.

104
00:04:33,160 --> 00:04:35,920
That kind of track record speaks volumes.

105
00:04:35,920 --> 00:04:37,000
Okay, that makes sense.

106
00:04:37,000 --> 00:04:38,640
Let's shift gears a bit.

107
00:04:38,640 --> 00:04:40,400
Security and structure.

108
00:04:40,400 --> 00:04:43,710
Security is obviously critical, especially with data flying back and forth

109
00:04:43,710 --> 00:04:44,160
constantly.

110
00:04:44,160 --> 00:04:45,240
Absolutely paramount.

111
00:04:45,240 --> 00:04:49,440
The sources mentioned that for the on-premise versions, that's the pro and the open

112
00:04:49,440 --> 00:04:49,720
source

113
00:04:49,720 --> 00:04:51,280
one. Right. The ones you host yourself.

114
00:04:51,280 --> 00:04:55,360
All the real time data, maybe sensitive chat messages, stays entirely on your

115
00:04:55,360 --> 00:04:55,760
servers.

116
00:04:55,760 --> 00:04:59,160
Correct. It never has to be sent to a third party service provider.

117
00:04:59,160 --> 00:05:00,480
And the significance of that is?

118
00:05:00,480 --> 00:05:04,400
It's huge. It means you maintain complete data sovereignty.

119
00:05:04,400 --> 00:05:07,080
This makes the setup inherently more secure.

120
00:05:07,080 --> 00:05:12,080
And crucially, it helps meet strict compliance requirements like IPA in health care.

121
00:05:12,080 --> 00:05:13,440
Ah, IPC.

122
00:05:13,440 --> 00:05:18,240
Right. So if you're handling patient information, you can't just route it through

123
00:05:18,240 --> 00:05:18,520
some

124
00:05:18,520 --> 00:05:19,840
random cloud service.

125
00:05:19,840 --> 00:05:25,080
Precisely. Keeping it on-premise under your control is often non-negotiable for

126
00:05:25,080 --> 00:05:25,480
that kind

127
00:05:25,480 --> 00:05:26,480
of sensitive data.

128
00:05:26,480 --> 00:05:30,600
Makes sense. OK, from security to code structure.

129
00:05:30,600 --> 00:05:33,960
The system provides time-tested abstractions.

130
00:05:33,960 --> 00:05:35,760
What does that mean for a developer?

131
00:05:35,760 --> 00:05:39,360
It means you get building blocks that guide you towards cleaner code.

132
00:05:39,360 --> 00:05:43,320
Things like channels, which are like isolated communication lines for specific

133
00:05:43,320 --> 00:05:43,880
features.

134
00:05:43,880 --> 00:05:46,760
So maybe one channel for chat, another for notifications.

135
00:05:46,800 --> 00:05:51,960
Exactly. And things like handling subscriptions automatically and presence tracking,

136
00:05:51,960 --> 00:05:54,080
basically, knowing who's online right now.

137
00:05:54,080 --> 00:05:57,560
These aren't novel ideas, but having them built in and robust helps you write

138
00:05:57,560 --> 00:05:59,360
maintainable code from day one.

139
00:05:59,360 --> 00:06:03,000
And the sources mentioned higher level stuff like collaboration features are coming

140
00:06:03,000 --> 00:06:05,880
soon. Yeah, seems like they're building on that solid foundation.

141
00:06:05,880 --> 00:06:07,480
What about the infrastructure needed?

142
00:06:07,480 --> 00:06:10,320
Does this require a whole bunch of extra complex servers?

143
00:06:10,320 --> 00:06:14,560
Surprisingly, no. The sources emphasize simplicity here.

144
00:06:15,320 --> 00:06:20,000
At its core, AnyCable uses a standard HTTP API,

145
00:06:20,000 --> 00:06:24,400
which every developer understands, and an embedded NATS PubSub server.

146
00:06:24,400 --> 00:06:27,520
Okay, NATS. Can you explain that briefly for the learner?

147
00:06:27,520 --> 00:06:30,640
Sure. NATS is a high-performance messaging system.

148
00:06:30,640 --> 00:06:34,520
Think of it like a super fast, reliable switchboard for data.

149
00:06:34,520 --> 00:06:38,600
It makes sure messages published by one part of the system get delivered quickly

150
00:06:38,600 --> 00:06:41,760
to all the interested subscribers. AnyCable bundles it in.

151
00:06:41,800 --> 00:06:46,080
But what if I already use something like Redis or even a standalone NATS cluster?

152
00:06:46,080 --> 00:06:49,880
Then you can just configure any cable to use those instead. It's flexible.

153
00:06:49,880 --> 00:06:53,200
It adapts to your existing setup rather than forcing a whole new stack on you.

154
00:06:53,200 --> 00:06:55,440
Okay. That's good to know. Let's make this more concrete.

155
00:06:55,440 --> 00:06:59,720
Where do these features, the reliability, the on-premise security really shine?

156
00:06:59,720 --> 00:07:02,160
Let's talk use cases. Right. Real world examples.

157
00:07:02,160 --> 00:07:06,200
The highest stakes one seems to be secure chats for health tech. You mentioned IPA.

158
00:07:06,200 --> 00:07:09,400
Yeah, because the pro version can be entirely self-hosted.

159
00:07:09,440 --> 00:07:11,960
It meets that strict IPA compliance standard.

160
00:07:11,960 --> 00:07:15,360
This is a huge deal for real time communication in health care.

161
00:07:15,360 --> 00:07:20,280
And the sources say it's actually used by some large patient doctor communication

162
00:07:20,280 --> 00:07:25,120
platforms. That's right. And in that context, reliability isn't just nice to have.

163
00:07:25,120 --> 00:07:28,040
Missed messages could have serious consequences.

164
00:07:28,040 --> 00:07:32,200
We're talking about software potentially involved in monitoring patients or

165
00:07:32,200 --> 00:07:35,040
delivering urgent updates. Wow. Okay.

166
00:07:35,040 --> 00:07:38,440
So reliability down to the second really matters there. Absolutely.

167
00:07:38,480 --> 00:07:43,280
What about something less critical, maybe more UX focused?

168
00:07:43,280 --> 00:07:46,400
Well, there's the streaming AI responses example.

169
00:07:46,400 --> 00:07:49,360
Think about interacting with chat GPT or similar models.

170
00:07:49,360 --> 00:07:52,080
You don't want that long pause while it thinks. Exactly.

171
00:07:52,080 --> 00:07:56,520
Applications are using any cable to stream the response back as it's being

172
00:07:56,520 --> 00:08:00,680
generated. Sometimes literally syllable by syllable, but feels instantaneous.

173
00:08:00,680 --> 00:08:04,960
Precisely. It dramatically reduces the perceived waiting time, better user

174
00:08:04,960 --> 00:08:07,560
experience, which often leads to better user retention.

175
00:08:07,600 --> 00:08:08,960
That's a direct business benefit.

176
00:08:08,960 --> 00:08:12,040
Makes sense. And for web developers, there's Hotwire at scale.

177
00:08:12,040 --> 00:08:13,400
Can you explain Hotwire quickly?

178
00:08:13,400 --> 00:08:18,480
Sure. Hotwire is an approach popular in the Rails ones, but usable elsewhere,

179
00:08:18,480 --> 00:08:23,160
where you send fully formed HTML snippets from the server over the web socket

180
00:08:23,160 --> 00:08:25,760
connection, instead of just raw data like JSON.

181
00:08:25,760 --> 00:08:28,280
The server does the rendering, the browser just slots it in.

182
00:08:28,280 --> 00:08:32,240
Kind of, yeah. Any cable acts like a performance booster for this,

183
00:08:32,240 --> 00:08:36,560
making sure those HTML updates arrive instantly, keeping the UI feeling snappy.

184
00:08:36,640 --> 00:08:38,920
And the pro version adds binary compression.

185
00:08:38,920 --> 00:08:42,800
Yep. Making those HTML snippets even smaller and faster to send,

186
00:08:42,800 --> 00:08:46,360
especially useful when you're pushing updates to lots of users simultaneously.

187
00:08:46,360 --> 00:08:51,000
So health tech, AI, web dev, any other interesting areas?

188
00:08:51,000 --> 00:08:54,800
The sources mentioned quite a variety, scalable chat apps, obviously,

189
00:08:54,800 --> 00:08:58,640
live updates for online events, but also more specialized things,

190
00:08:58,640 --> 00:09:03,160
like processing real time voice streams from APIs, like Twilio media streams,

191
00:09:03,160 --> 00:09:07,560
often using Go on the back end, and also internet of things, IoT applications.

192
00:09:07,560 --> 00:09:09,520
Oh, what kind of IoT data?

193
00:09:09,520 --> 00:09:13,000
Things like streaming GPS coordinates from vehicles or handling data

194
00:09:13,000 --> 00:09:17,360
from electric vehicle charging stations using a specific standard called OCPP.

195
00:09:17,360 --> 00:09:19,200
Yeah, open charge point protocol.

196
00:09:19,200 --> 00:09:22,360
It's the standard for communication between EV chargers

197
00:09:22,360 --> 00:09:24,160
and central management systems.

198
00:09:24,160 --> 00:09:27,280
So any cable is handling that real time flow, too.

199
00:09:27,280 --> 00:09:30,480
Wow. OK, so it really spans from critical health care

200
00:09:30,480 --> 00:09:33,960
chat to managing EV infrastructure.

201
00:09:33,960 --> 00:09:35,080
That's quite a range.

202
00:09:35,080 --> 00:09:39,760
It definitely highlights the versatility of a robust real time layer.

203
00:09:39,760 --> 00:09:42,760
All right. So for our learner listener, if they're thinking,

204
00:09:42,760 --> 00:09:45,120
OK, this sounds useful, how do they get started?

205
00:09:45,120 --> 00:09:46,200
What are the options?

206
00:09:46,200 --> 00:09:48,440
The sources mentioned three main paths.

207
00:09:48,440 --> 00:09:51,440
Yeah, which is great for different needs and budgets.

208
00:09:51,440 --> 00:09:55,520
First up, there's the managed sauce option software as a service. Right.

209
00:09:55,520 --> 00:09:59,520
This is where the AnyCable team runs and manages AnyCable Pro for you.

210
00:09:59,840 --> 00:10:02,880
The sources say it's currently free for early users.

211
00:10:02,880 --> 00:10:05,280
So lowest friction way to try it out, basically. Absolutely.

212
00:10:05,280 --> 00:10:08,400
Perfect for validating an idea without worrying about server setup.

213
00:10:08,400 --> 00:10:09,880
Then there's the Pro version.

214
00:10:09,880 --> 00:10:13,360
This is the one you pay for and run yourself on premise. Correct.

215
00:10:13,360 --> 00:10:15,680
It's fourteen hundred and ninety dollars per year.

216
00:10:15,680 --> 00:10:17,600
And that gives you unlimited instances.

217
00:10:17,600 --> 00:10:20,880
So you can scale it out as much as you need within your own infrastructure.

218
00:10:20,880 --> 00:10:23,600
And this is the version with the extra benefits.

219
00:10:23,600 --> 00:10:26,560
Yeah. The sources highlight it's about twice as memory efficient

220
00:10:26,560 --> 00:10:30,360
as the open source one has features like adaptive scaling based on load,

221
00:10:30,360 --> 00:10:32,280
that binary compression we mentioned.

222
00:10:32,280 --> 00:10:34,800
And you get dedicated support from the team. OK.

223
00:10:34,800 --> 00:10:38,280
And finally, the open source version, which is completely free.

224
00:10:38,280 --> 00:10:41,920
You can grab the code, deploy it using standard tools like Docker

225
00:10:41,920 --> 00:10:46,520
or Kubernetes on any cloud provider, Heroku, AWS, wherever.

226
00:10:46,520 --> 00:10:48,520
And it still has the core features. Oh, yeah.

227
00:10:48,520 --> 00:10:51,240
Hotwire support, the crucial consistency guarantees

228
00:10:51,240 --> 00:10:55,480
and built in authentication using JWT. JWT. Remind us.

229
00:10:55,800 --> 00:10:58,520
JSON Web Token. It's a secure way for the server

230
00:10:58,520 --> 00:11:01,200
to verify who the user is for each real time message

231
00:11:01,200 --> 00:11:03,760
without constantly sending passwords back and forth.

232
00:11:03,760 --> 00:11:05,600
Very standard, very secure.

233
00:11:05,600 --> 00:11:08,320
What seems really interesting here, looking at the sources,

234
00:11:08,320 --> 00:11:10,920
is the flexibility to move between these options.

235
00:11:10,920 --> 00:11:12,000
That's a key point.

236
00:11:12,000 --> 00:11:14,880
You could start with the free manage SAAS to test things out.

237
00:11:14,880 --> 00:11:18,320
Then maybe as your app grows and SAAS costs start climbing,

238
00:11:18,320 --> 00:11:23,160
you might switch to the fixed cost pro license for predictable budgeting at scale.

239
00:11:23,880 --> 00:11:25,920
Or if you have the team and resources,

240
00:11:25,920 --> 00:11:29,920
you could move to the free open source version and manage everything yourself.

241
00:11:29,920 --> 00:11:31,640
And the really critical detail.

242
00:11:31,640 --> 00:11:33,800
The sources state very clearly,

243
00:11:33,800 --> 00:11:36,680
no changes are needed in your actual application code

244
00:11:36,680 --> 00:11:39,160
to switch between SAAS, pro or open source.

245
00:11:39,160 --> 00:11:41,640
The core API is the same.

246
00:11:41,640 --> 00:11:42,800
That's huge.

247
00:11:42,800 --> 00:11:46,520
Avoids a massive rewrite just because your hosting model changes.

248
00:11:46,520 --> 00:11:49,960
Invaluable flexibility, especially for a growing product.

249
00:11:49,960 --> 00:11:52,960
And if you do need help, say setting up the pro version

250
00:11:53,160 --> 00:11:55,760
or preparing for a huge launch.

251
00:11:55,760 --> 00:11:57,480
Consulting is available.

252
00:11:57,480 --> 00:12:00,480
The sources mentioned $200 per hour for help with setup,

253
00:12:00,480 --> 00:12:03,320
deployment strategies, even preparing for load tests

254
00:12:03,320 --> 00:12:05,560
to make sure you can handle the scale you expect.

255
00:12:05,560 --> 00:12:07,480
Good to have that safety net. Definitely.

256
00:12:07,480 --> 00:12:09,080
OK, let's try to wrap this up.

257
00:12:09,080 --> 00:12:11,160
Synthesizing everything from this deep dive.

258
00:12:11,160 --> 00:12:15,560
It really shows that reliable real time isn't just about opening a basic connection.

259
00:12:15,560 --> 00:12:19,720
It's about tackling the inherent flakiness of the Internet.

260
00:12:19,720 --> 00:12:22,000
Right. The dropped packets, the spotty connections.

261
00:12:22,160 --> 00:12:27,570
Yeah. A dedicated server like AnyCable anticipates that fragility and compensates

262
00:12:27,570 --> 00:12:27,880
for it,

263
00:12:27,880 --> 00:12:31,440
turning those potential loss messages into guaranteed delivery.

264
00:12:31,440 --> 00:12:33,840
And that removes a massive headache for developers.

265
00:12:33,840 --> 00:12:38,160
A huge one. Whether you're building a simple chat or a life critical health care

266
00:12:38,160 --> 00:12:38,480
app,

267
00:12:38,480 --> 00:12:42,160
you don't have to become an expert in low level network resilience.

268
00:12:42,160 --> 00:12:45,760
So what does this all mean for you, the listener, when making choices?

269
00:12:45,760 --> 00:12:49,960
It means you can have both reliable, low latency communication

270
00:12:50,080 --> 00:12:54,560
and full control over your sensitive data, especially with the on-premise options.

271
00:12:54,560 --> 00:12:58,320
Which opens the door for those critical applications in health tech, finance, etc.

272
00:12:58,320 --> 00:13:01,520
But it also just makes for a better user experience in any app.

273
00:13:01,520 --> 00:13:05,440
That instant feedback from AI, the smooth collaboration,

274
00:13:05,440 --> 00:13:10,000
the immediate updates that drives engagement and retention, real business value.

275
00:13:10,000 --> 00:13:13,200
OK, time for our final provocative thought for you to consider.

276
00:13:13,200 --> 00:13:18,160
We saw that AnyCable Pro has a fixed annual cost $1,490, no matter how many users

277
00:13:18,160 --> 00:13:18,560
you have.

278
00:13:18,560 --> 00:13:20,080
Right, flat fee for the license.

279
00:13:20,080 --> 00:13:22,320
But a typical managed sauce service.

280
00:13:22,320 --> 00:13:24,480
The cost usually scales with usage.

281
00:13:24,480 --> 00:13:27,920
More users, more messages, higher bill, often exponentially.

282
00:13:27,920 --> 00:13:30,160
Pay as you go.

283
00:13:30,160 --> 00:13:31,440
So here's the question.

284
00:13:31,440 --> 00:13:36,640
For a product that you expect to grow very quickly, at what point does that upfront,

285
00:13:36,640 --> 00:13:41,760
fixed investment in an on-premise license like Pro become more cost-effective,

286
00:13:41,760 --> 00:13:46,740
purely mathematically, than the inevitably rising recurring costs of a usage-based

287
00:13:46,740 --> 00:13:47,440
managed service?

288
00:13:48,080 --> 00:13:49,600
When does the math flip?

289
00:13:49,600 --> 00:13:52,640
That's a great calculation to think about when planning for scale.

290
00:13:52,640 --> 00:13:53,520
Something to mull over.

291
00:13:53,520 --> 00:13:57,990
Before we sign off, one more huge thank you to our supporter for this deep dive,

292
00:13:57,990 --> 00:13:58,800
Safe Server.

293
00:13:58,800 --> 00:14:00,400
Yes, thank you, Safe Server.

294
00:14:00,400 --> 00:14:04,400
Remember to visit www.safe-server.de.

295
00:14:04,400 --> 00:14:06,960
They can help with your hosting, digital transformation,

296
00:14:06,960 --> 00:14:09,120
and getting platforms like AnyCable running strong.

297
00:14:09,120 --> 00:14:11,520
That's www.safe-server.de.

298
00:14:11,520 --> 00:14:12,480
Check them out.

299
00:14:12,480 --> 00:14:14,480
All right, that's all the time we have for this deep dive

300
00:14:14,480 --> 00:14:17,680
into the world of guaranteed real-time communication with AnyCable.

301
00:14:17,680 --> 00:14:18,960
Thanks for learning with us.

302
00:14:18,960 --> 00:14:19,960
Thanks, everyone.

303
00:14:19,960 --> 00:14:21,440
We'll see you next time on the Deep Dive.