1
00:00:00,000 --> 00:00:04,680
Welcome back to the Deep Dive. Today, we're really diving into the ROI of open

2
00:00:04,680 --> 00:00:04,960
source,

3
00:00:04,960 --> 00:00:09,360
specifically in your marketing stack. And we're focusing pretty intently on DittoFeed.

4
00:00:09,360 --> 00:00:09,680
It's this

5
00:00:09,680 --> 00:00:14,560
platform that's making some big promises about ending, well, the hitting costs of

6
00:00:14,560 --> 00:00:15,360
vendor lock-in

7
00:00:15,360 --> 00:00:19,600
and those rising prices for customer communication. Our mission today, especially

8
00:00:19,600 --> 00:00:20,400
for you, the learner

9
00:00:20,400 --> 00:00:25,120
listening in, is to really pull apart how a platform like DittoFeed gives you that

10
00:00:25,120 --> 00:00:25,600
crucial

11
00:00:26,240 --> 00:00:30,240
escape hatch from expensive systems. We're going to break down the features,

12
00:00:30,240 --> 00:00:30,640
journeys,

13
00:00:30,640 --> 00:00:34,320
embedded components, all that stuff. So anyone, really, whether you're a CTO or

14
00:00:34,320 --> 00:00:34,880
maybe a marketing

15
00:00:34,880 --> 00:00:39,440
specialist, can get the technical benefits and just the sheer flexibility it offers.

16
00:00:39,440 --> 00:00:41,930
Flexibility really is the key word, isn't it? When we talk about customer

17
00:00:41,930 --> 00:00:43,360
engagement, what we mean is

18
00:00:43,360 --> 00:00:47,040
the whole infrastructure that automates, well, pretty much every message between a

19
00:00:47,040 --> 00:00:47,360
business

20
00:00:47,360 --> 00:00:51,520
and its users. That covers the marketing side, think newsletters, those onboarding

21
00:00:51,520 --> 00:00:51,920
campaigns,

22
00:00:51,920 --> 00:00:56,640
and also the transactional stuff, you know, receipts, password resets, appointment

23
00:00:56,640 --> 00:00:57,120
reminders,

24
00:00:57,120 --> 00:01:01,680
all those critical messages. And Data Feed's goal here is quite straightforward, be

25
00:01:01,680 --> 00:01:02,160
that

26
00:01:02,160 --> 00:01:08,560
comprehensive omni-channel layer, so handling email, SMS, and more. And crucially,

27
00:01:08,560 --> 00:01:08,960
doing it

28
00:01:08,960 --> 00:01:13,440
as a genuinely developer-friendly and, well, sustainable alternative to the big

29
00:01:13,440 --> 00:01:14,000
proprietary

30
00:01:14,000 --> 00:01:18,420
names like, say, customer.io. Okay, before we really unpack this whole open-source

31
00:01:18,420 --> 00:01:18,720
angle,

32
00:01:18,720 --> 00:01:22,680
which sounds fascinating, we need to give a quick shout out to the supporter of

33
00:01:22,680 --> 00:01:23,920
this deep dive,

34
00:01:23,920 --> 00:01:28,480
Safe Server. Safe Server handles software hosting, and they support your digital

35
00:01:28,480 --> 00:01:29,120
transformation

36
00:01:29,120 --> 00:01:33,310
journey. They make sure your, you know, complex infrastructure is solid and

37
00:01:33,310 --> 00:01:34,640
reliable. And they

38
00:01:34,640 --> 00:01:38,320
specifically help with hosting software just like Ditto Feed. You can find out much

39
00:01:38,320 --> 00:01:38,880
more about how

40
00:01:38,880 --> 00:01:44,430
they can support you at www.safeserver.de. So big thanks to Safe Server for

41
00:01:44,430 --> 00:01:45,920
supporting us.

42
00:01:45,920 --> 00:01:49,120
Now let's get back to those core problems you mentioned, especially that threat of

43
00:01:49,120 --> 00:01:53,200
vendor lock-in. For businesses may be burned by older providers, what does that

44
00:01:53,200 --> 00:01:53,920
trap actually

45
00:01:53,920 --> 00:01:58,310
look like day to day? Oh, it looks like paralysis really. Vendor lock-in, it

46
00:01:58,310 --> 00:01:59,520
happens when the cost

47
00:01:59,520 --> 00:02:03,520
and the sheer complexity of moving all your user data, your messaging setups away

48
00:02:03,520 --> 00:02:04,400
from one platform

49
00:02:04,400 --> 00:02:09,910
just becomes, well, prohibitive, too expensive, too risky. So you end up stuck. You're

50
00:02:09,910 --> 00:02:10,400
often paying

51
00:02:10,400 --> 00:02:13,950
these ever-increasing fees based on volume because the operational headache, the

52
00:02:13,950 --> 00:02:14,560
risk of actually

53
00:02:14,560 --> 00:02:18,980
moving is just too high. Right. And what's really interesting here is how DittoFeed

54
00:02:18,980 --> 00:02:19,520
tackles this

55
00:02:19,520 --> 00:02:24,210
head-on using that open source philosophy. It's not just software. It feels more

56
00:02:24,210 --> 00:02:25,360
like an insurance

57
00:02:25,360 --> 00:02:28,560
policy. Exactly. That's a great way to put it. They actually call it the escape

58
00:02:28,560 --> 00:02:30,000
hatch. See,

59
00:02:30,000 --> 00:02:36,080
DittoFeed is MIT licensed, the source code, completely open, totally free. So users

60
00:02:36,080 --> 00:02:36,240
can

61
00:02:36,240 --> 00:02:40,200
start with their cloud offering, which is super convenient for getting up and

62
00:02:40,200 --> 00:02:41,120
running fast.

63
00:02:41,120 --> 00:02:46,060
But crucially, if they ever face aggressive price hikes or maybe their compliance

64
00:02:46,060 --> 00:02:47,040
needs change,

65
00:02:47,040 --> 00:02:51,120
they have a clear documented way to switch to self-hosting it themselves.

66
00:02:51,120 --> 00:02:54,480
And this is important. They actually provide technical support to help with that

67
00:02:54,480 --> 00:02:55,200
transition.

68
00:02:55,200 --> 00:03:00,080
Okay. But let's be real for a second. When you trade volume-based pricing for self-hosting,

69
00:03:00,080 --> 00:03:03,600
aren't you potentially swapping one kind of headache for another? I mean, managing

70
00:03:03,600 --> 00:03:06,810
infrastructure like Clickhouse and Temporal, that's not trivial, right? What's the

71
00:03:06,810 --> 00:03:07,760
real trade-off?

72
00:03:07,760 --> 00:03:11,760
That's a really important question. The trade-off is definitely management

73
00:03:11,760 --> 00:03:12,960
complexity, yes,

74
00:03:12,960 --> 00:03:18,480
but what you gain is ultimate control. And for many organizations, especially those

75
00:03:18,480 --> 00:03:19,040
handling

76
00:03:19,040 --> 00:03:23,620
sensitive PII, you know, personally identifiable information, or maybe those with

77
00:03:23,620 --> 00:03:24,480
really solid

78
00:03:24,480 --> 00:03:29,250
engineering teams, that control is absolutely worth the effort. Think about those

79
00:03:29,250 --> 00:03:29,600
payroll

80
00:03:29,600 --> 00:03:34,240
and HR companies mentioned in the source material. They explicitly chose DittoFeed

81
00:03:34,240 --> 00:03:34,960
to hedge against

82
00:03:34,960 --> 00:03:39,720
lock-in. Because for them, being trapped isn't just a cost risk, it's a security

83
00:03:39,720 --> 00:03:40,560
risk too.

84
00:03:40,560 --> 00:03:44,170
They much prefer owning their data, owning their infrastructure. It guarantees

85
00:03:44,170 --> 00:03:44,960
price stability

86
00:03:44,960 --> 00:03:48,880
and compliance basically forever. That makes a lot of sense, investing in control.

87
00:03:48,880 --> 00:03:53,450
So structurally, who is this really built for? The sources seem to stress that

88
00:03:53,450 --> 00:03:53,840
while it's

89
00:03:53,840 --> 00:03:58,390
architected for massive scale, like millions of users, the UI is deliberately kept

90
00:03:58,390 --> 00:03:59,120
simple enough

91
00:03:59,120 --> 00:04:03,600
for non-technical team members to actually build and launch campaigns. So it sounds

92
00:04:03,600 --> 00:04:04,160
like it's for

93
00:04:04,160 --> 00:04:08,400
almost any organization needing to record messages. Exactly. And we see it being

94
00:04:08,400 --> 00:04:08,720
used

95
00:04:08,720 --> 00:04:12,870
really effectively in some pretty cutting edge places, specifically in DevTools

96
00:04:12,870 --> 00:04:13,280
companies,

97
00:04:13,280 --> 00:04:18,240
right? Their head of growth teams found DittoFeed, well, indispensable for their

98
00:04:18,240 --> 00:04:19,200
product-led growth

99
00:04:19,200 --> 00:04:23,960
tech stacks, their POG stacks. By automating really high quality onboarding

100
00:04:23,960 --> 00:04:24,800
sequences,

101
00:04:24,800 --> 00:04:29,330
they actually cited a direct improvement in time to value TTV for their new

102
00:04:29,330 --> 00:04:30,080
customers.

103
00:04:30,080 --> 00:04:33,860
And that's huge because it directly boosts conversion rates. It sort of bridges

104
00:04:33,860 --> 00:04:34,400
that gap

105
00:04:34,400 --> 00:04:38,720
between engineering power and marketing execution. Bridging the gap. Okay. That

106
00:04:38,720 --> 00:04:39,440
leads us perfectly

107
00:04:39,440 --> 00:04:43,300
into the low code toolkit. Section two, how this automation actually works under

108
00:04:43,300 --> 00:04:43,920
the hood.

109
00:04:43,920 --> 00:04:48,160
The idea seems to be once engineering hooks up the data initially, the marketing

110
00:04:48,160 --> 00:04:48,880
and growth teams

111
00:04:48,880 --> 00:04:53,080
can pretty much run with it, building complex sequences themselves. Yeah. And to

112
00:04:53,080 --> 00:04:53,440
understand

113
00:04:53,440 --> 00:04:57,300
how that automation works, especially if you're maybe newer to this, you really

114
00:04:57,300 --> 00:04:58,160
just need to get

115
00:04:58,160 --> 00:05:02,800
your head around three core components. Think of it like a, like a low code recipe

116
00:05:02,800 --> 00:05:03,440
book that runs

117
00:05:03,440 --> 00:05:07,020
itself once you set it up. So first you've got journeys. This is your main

118
00:05:07,020 --> 00:05:08,080
automation canvas.

119
00:05:08,080 --> 00:05:12,480
It's a visual drag and drop interface where you map out these multi-step, multi-trigger

120
00:05:12,480 --> 00:05:12,960
sequences,

121
00:05:12,960 --> 00:05:17,040
but it's not just a basic flow chart, you know, that's smarter than that.

122
00:05:17,040 --> 00:05:20,990
It includes things like integrated branch-based analytics. So you can actually see

123
00:05:20,990 --> 00:05:21,440
how tweaks

124
00:05:21,440 --> 00:05:25,970
affect performance right there. And it respects local time zones, which sounds

125
00:05:25,970 --> 00:05:27,040
small, but it

126
00:05:27,040 --> 00:05:30,270
prevents those really embarrassing middle of the night messages going to users

127
00:05:30,270 --> 00:05:31,360
across the globe,

128
00:05:31,360 --> 00:05:36,000
a detail older systems often get wrong. Okay. Journeys make sense. Visual flows.

129
00:05:36,000 --> 00:05:41,200
Next up is segments. This sounds like where the real targeting power comes in. For

130
00:05:41,200 --> 00:05:41,760
a beginner,

131
00:05:41,760 --> 00:05:45,960
maybe think of it like super advanced Excel filters, but running live against user

132
00:05:45,960 --> 00:05:46,400
data.

133
00:05:46,400 --> 00:05:50,350
That's a perfect analogy, actually. Segments are exactly that, the tool you use to

134
00:05:50,350 --> 00:05:51,040
slice and dice

135
00:05:51,040 --> 00:05:54,750
your user base. And it's based on what they do, their actions and who they are,

136
00:05:54,750 --> 00:05:55,840
their properties.

137
00:05:55,840 --> 00:06:01,040
So you can combine things like, say, viewed pricing page and event with identified

138
00:06:01,040 --> 00:06:01,360
traits

139
00:06:01,360 --> 00:06:05,900
like subscription status, trial expired. The real power comes from the unlimited

140
00:06:05,900 --> 00:06:06,720
and or conditions.

141
00:06:06,720 --> 00:06:10,640
It lets you get incredibly precise. You go way beyond just blasting an email to

142
00:06:10,640 --> 00:06:14,800
everyone subscribed. Instead, you target like everyone who viewed feature X twice

143
00:06:14,800 --> 00:06:15,120
this week,

144
00:06:15,120 --> 00:06:18,720
but hasn't finished setting up their profile yet. Hyper targeted.

145
00:06:18,720 --> 00:06:23,280
Got it. Journeys for the flow, segments for the who. And finally, the message

146
00:06:23,280 --> 00:06:24,640
itself has to live

147
00:06:24,640 --> 00:06:27,440
somewhere. That's templates, right? The content layer.

148
00:06:27,440 --> 00:06:32,000
Exactly. Templates where you craft the actual message and inject that personalization

149
00:06:32,000 --> 00:06:32,800
magic.

150
00:06:32,800 --> 00:06:37,380
And users get flexibility here too. They can use a sort of notion-like low code

151
00:06:37,380 --> 00:06:37,840
editor,

152
00:06:37,840 --> 00:06:42,080
which is great for quick content. Or if they need more control, they can dive into

153
00:06:42,080 --> 00:06:43,040
full HTML or

154
00:06:43,040 --> 00:06:47,840
MJML for really polished designs. The key ingredient is the liquid syntax they use

155
00:06:47,840 --> 00:06:48,000
for

156
00:06:48,000 --> 00:06:51,670
personalization. That's pretty much the standard way to securely pull in user

157
00:06:51,670 --> 00:06:52,560
details, name,

158
00:06:52,560 --> 00:06:56,650
company, maybe their last login date, making sure every message feels relevant and

159
00:06:56,650 --> 00:06:57,360
tailored.

160
00:06:57,360 --> 00:07:00,960
Okay, before we jump into the more technical setup, let's talk reach. Because we're

161
00:07:00,960 --> 00:07:01,120
not

162
00:07:01,120 --> 00:07:06,080
just talking emails here anymore, are we? The sources emphasize this is truly omnichannel.

163
00:07:06,080 --> 00:07:10,830
Oh, absolutely. The platform handles standard email and SMS directly, out of the

164
00:07:10,830 --> 00:07:11,520
box. But

165
00:07:11,520 --> 00:07:16,560
its real flexibility comes from webhooks. Webhooks act as this crucial integration

166
00:07:16,560 --> 00:07:17,520
bridge. They let

167
00:07:17,520 --> 00:07:21,890
you trigger a message or an action in almost any other system. We're talking mobile

168
00:07:21,890 --> 00:07:23,040
push notifications

169
00:07:23,040 --> 00:07:28,160
via another service, maybe messages in Slack, WhatsApp, even custom internal tools.

170
00:07:28,160 --> 00:07:28,640
This means

171
00:07:28,640 --> 00:07:32,910
one single automation journey can reach the user wherever is most effective,

172
00:07:32,910 --> 00:07:33,280
whether that's a

173
00:07:33,280 --> 00:07:37,720
welcome email or a critical password reset alert pinging their phone. That unified

174
00:07:37,720 --> 00:07:38,400
approach seems

175
00:07:38,400 --> 00:07:42,070
like a perfect lead-in to Section 3, which sounds like the real aha moment,

176
00:07:42,070 --> 00:07:43,200
especially for product

177
00:07:43,200 --> 00:07:47,040
developers. Embedded components. The source has mentioned significant savings in

178
00:07:47,040 --> 00:07:47,920
engineering time

179
00:07:47,920 --> 00:07:52,400
here. Huge savings. Yeah, think about building a customer engagement platform

180
00:07:52,400 --> 00:07:53,360
inside your own

181
00:07:53,360 --> 00:07:57,420
product from scratch. You know, complete with a decent template editor, a segmentation

182
00:07:57,420 --> 00:07:57,920
engine,

183
00:07:57,920 --> 00:08:02,700
a journey builder. It's a massive, massive project. Embedded components let

184
00:08:02,700 --> 00:08:04,240
developers take any part

185
00:08:04,240 --> 00:08:08,420
of the Ditto feed dashboard, the journey builder, the template editor, whatever,

186
00:08:08,420 --> 00:08:08,960
and embed it

187
00:08:08,960 --> 00:08:13,030
directly inside their own sauce application. And technically it's pretty

188
00:08:13,030 --> 00:08:14,400
straightforward. They offer

189
00:08:14,400 --> 00:08:18,850
either a simple iframe or an unstyled react component. So imagine if you sell, I

190
00:08:18,850 --> 00:08:19,520
don't know,

191
00:08:19,520 --> 00:08:23,650
a business analytics tool and your customers need to send messages based on the

192
00:08:23,650 --> 00:08:24,640
insights from your

193
00:08:24,640 --> 00:08:28,670
tool. Instead of building that messaging feature yourself, you can just embed Ditto

194
00:08:28,670 --> 00:08:29,840
feeds components.

195
00:08:29,840 --> 00:08:33,440
Instantly you offer your customers a full marketing automation suite. The source

196
00:08:33,440 --> 00:08:33,840
material

197
00:08:33,840 --> 00:08:38,110
mentioned building this internally could take a year or more, a whole year. For

198
00:08:38,110 --> 00:08:39,040
listeners maybe not

199
00:08:39,040 --> 00:08:42,640
deep in sauce development, why is replicating something like a good template editor

200
00:08:42,640 --> 00:08:43,520
or segmentation

201
00:08:43,520 --> 00:08:47,520
engine so time consuming? Right, it's not just the initial build effort which is

202
00:08:47,520 --> 00:08:48,160
significant.

203
00:08:48,160 --> 00:08:51,930
It's the ongoing maintenance, keeping up with features, dealing with all the edge

204
00:08:51,930 --> 00:08:52,480
cases.

205
00:08:52,480 --> 00:08:56,430
Building a resilient segmentation engine means handling potentially vast amounts of

206
00:08:56,430 --> 00:08:56,960
real-time

207
00:08:56,960 --> 00:09:02,220
data, complex query logic, performance tuning. Building a good visual editor means

208
00:09:02,220 --> 00:09:02,640
wrestling

209
00:09:02,640 --> 00:09:08,240
with UI UX, versioning, email client rendering quirks which are notoriously painful,

210
00:09:08,240 --> 00:09:08,560
and keeping

211
00:09:08,560 --> 00:09:13,920
APIs updated. So yeah, that year or more estimate sounds about right for getting

212
00:09:13,920 --> 00:09:14,880
something robust.

213
00:09:14,880 --> 00:09:19,280
Plus, like the source says, the ongoing maintenance headache. Embedded components

214
00:09:19,280 --> 00:09:20,080
let you sidestep

215
00:09:20,080 --> 00:09:24,080
that entire massive cost and effort. And clearly this isn't just aimed at small

216
00:09:24,080 --> 00:09:24,800
startups needing

217
00:09:24,800 --> 00:09:28,950
a quick fix. For larger enterprise users, Ditto Feed offers some pretty robust

218
00:09:28,950 --> 00:09:30,240
control features.

219
00:09:30,240 --> 00:09:34,370
It's noted as the only open source platform in this space offering programmatic

220
00:09:34,370 --> 00:09:34,960
control over

221
00:09:34,960 --> 00:09:39,380
multiple workspaces. That's right. And that control is absolutely essential for,

222
00:09:39,380 --> 00:09:40,720
say, agencies managing

223
00:09:40,720 --> 00:09:45,600
multiple clients or large companies with different brands or divisions. Programmatic

224
00:09:45,600 --> 00:09:46,160
control means

225
00:09:46,160 --> 00:09:51,040
you can manage these workspaces via API, ensuring complete data isolation between

226
00:09:51,040 --> 00:09:51,840
each client or

227
00:09:51,840 --> 00:09:56,320
brand. Plus, they offer white labeling and custom branding options. So when you

228
00:09:56,320 --> 00:09:57,600
embed these components,

229
00:09:57,600 --> 00:10:02,640
it looks and feels seamlessly like part of your application to the end customer.

230
00:10:02,640 --> 00:10:06,270
Very professional. Okay, let's shift gears slightly and look under the hood. All

231
00:10:06,270 --> 00:10:06,800
this front-end

232
00:10:06,800 --> 00:10:10,530
flexibility and low-code stuff needs a solid foundation. And it sounds like this

233
00:10:10,530 --> 00:10:11,040
platform

234
00:10:11,040 --> 00:10:15,600
is really built with the developer, the engineer, who appreciates modern tech in

235
00:10:15,600 --> 00:10:16,400
mind. Oh,

236
00:10:16,400 --> 00:10:20,080
definitely. While the user experience aims for low-code simplicity, the core

237
00:10:20,080 --> 00:10:20,960
infrastructure

238
00:10:20,960 --> 00:10:25,400
is seriously cutting edge. It's a TypeScript application running on fast, scalable

239
00:10:25,400 --> 00:10:25,840
tech.

240
00:10:25,840 --> 00:10:30,160
You've got Postgres as the main database, ClickHouse, which is brilliant for

241
00:10:30,160 --> 00:10:30,640
handling

242
00:10:30,640 --> 00:10:35,120
high-volume event analytics really quickly, and Temporal for managing those complex,

243
00:10:35,120 --> 00:10:39,120
long-running workflows reliably. This kind of architecture is vital if you're going

244
00:10:39,120 --> 00:10:39,600
to handle

245
00:10:39,600 --> 00:10:43,960
potentially millions of user events streaming in. And the developer focus extends

246
00:10:43,960 --> 00:10:44,480
to how you

247
00:10:44,480 --> 00:10:49,320
interact with it. Full REST API access for getting data in and out, plus an Admin

248
00:10:49,320 --> 00:10:49,600
API,

249
00:10:49,600 --> 00:10:53,520
specifically for managing workspaces, programmatically key for automating setups.

250
00:10:54,080 --> 00:10:58,000
And they provide SDKs, too, for Web, Node.js, React Native,

251
00:10:58,000 --> 00:11:00,560
just to make that integration work smoother for development teams.

252
00:11:00,560 --> 00:11:05,120
I also noticed a focus on quality assurance and control, which sometimes gets

253
00:11:05,120 --> 00:11:05,600
missed when

254
00:11:05,600 --> 00:11:09,760
tools focus purely on speed. Things like branch-based Git workflows for managing

255
00:11:09,760 --> 00:11:13,120
campaign changes? That sounds pretty sophisticated.

256
00:11:13,120 --> 00:11:17,280
It is, and it's crucial for teams working collaboratively or needing proper version

257
00:11:17,280 --> 00:11:21,620
control and rollback capabilities for their messaging campaigns, just like with

258
00:11:21,620 --> 00:11:22,160
code.

259
00:11:22,160 --> 00:11:26,800
And alongside that, there's a testing SDK. This is really cool. It lets developers

260
00:11:26,800 --> 00:11:27,120
write

261
00:11:27,120 --> 00:11:30,960
automated tests for their messaging campaigns that can run in their continuous

262
00:11:30,960 --> 00:11:31,520
integration,

263
00:11:31,520 --> 00:11:36,000
their CI pipeline. This means you catch errors programmatically before a broken

264
00:11:36,000 --> 00:11:36,720
campaign

265
00:11:36,720 --> 00:11:41,360
ever reaches a real user. It avoids that nightmare scenario of trying to manually

266
00:11:41,360 --> 00:11:46,720
queue complex journeys in a live production environment. Saves time, protects users.

267
00:11:46,720 --> 00:11:50,400
And obviously, tying right back to our initial points about control and security,

268
00:11:50,400 --> 00:11:55,120
the ultimate developer feature. The ability to actually self-host the entire

269
00:11:55,120 --> 00:11:55,680
platform,

270
00:11:55,680 --> 00:12:00,020
protects sensitive PII inside your own walls. Exactly. It brings that control full

271
00:12:00,020 --> 00:12:00,560
circle.

272
00:12:00,560 --> 00:12:03,920
Control over the infrastructure, the data, the compliance, all the way through to

273
00:12:03,920 --> 00:12:04,000
the

274
00:12:04,000 --> 00:12:08,320
campaign logic and testing. Okay. Looking just briefly ahead now. The roadmap for

275
00:12:08,320 --> 00:12:09,440
2025 shows

276
00:12:09,440 --> 00:12:13,690
they're not standing still. What are some of the key things coming down the pipe?

277
00:12:13,690 --> 00:12:14,160
Yeah. It looks

278
00:12:14,160 --> 00:12:17,950
like they're moving towards more sophisticated ways of modeling users and

279
00:12:17,950 --> 00:12:18,960
relationships.

280
00:12:19,760 --> 00:12:24,720
For the first half of 2025, a big focus is on user grouping. This will let the

281
00:12:24,720 --> 00:12:26,000
platform understand

282
00:12:26,000 --> 00:12:30,870
and segment based on collections of users think like members of a specific team in

283
00:12:30,870 --> 00:12:31,600
a B2B app

284
00:12:31,600 --> 00:12:35,600
or users belonging to a particular club. That's really important for many business

285
00:12:35,600 --> 00:12:36,560
use cases.

286
00:12:36,560 --> 00:12:41,430
Then moving into Q2, they're planning identity resolution. This is super important

287
00:12:41,430 --> 00:12:42,000
for stitching

288
00:12:42,000 --> 00:12:46,480
together a user's journey across different devices or before and after they log in.

289
00:12:46,480 --> 00:12:50,080
So connecting that anonymous browsing behavior with the identified user profile

290
00:12:50,080 --> 00:12:51,280
once they sign up,

291
00:12:51,280 --> 00:12:55,280
it gives you that complete unified view of the customer. And further out, any plans

292
00:12:55,280 --> 00:12:55,600
mentioned

293
00:12:55,600 --> 00:13:00,080
to make the low code side even faster or smarter? Yes, for Q3 2025, they're looking

294
00:13:00,080 --> 00:13:00,720
at integrating

295
00:13:00,720 --> 00:13:05,350
LLM's large language models. The idea seems to be using AI to help generate initial

296
00:13:05,350 --> 00:13:05,840
drafts

297
00:13:05,840 --> 00:13:09,700
of journeys, segments, maybe even message templates based on natural language

298
00:13:09,700 --> 00:13:10,160
prompts.

299
00:13:10,160 --> 00:13:13,840
So speeding up that campaign creation process even more for marketing teams,

300
00:13:13,840 --> 00:13:19,600
letting them prototype faster. So if we kind of pull this all together, what does

301
00:13:19,600 --> 00:13:20,080
it all mean?

302
00:13:20,080 --> 00:13:23,960
I think the big takeaway is that Ditto Feed offers this knowledge hedge, perhaps.

303
00:13:23,960 --> 00:13:24,560
It gives you huge

304
00:13:24,560 --> 00:13:27,750
flexibility in that crucial self-hosting control to guard against rising costs and

305
00:13:27,750 --> 00:13:28,560
vendor lock-in.

306
00:13:28,560 --> 00:13:32,400
But it does this while also providing genuinely powerful low-code tools like

307
00:13:32,400 --> 00:13:33,280
journeys and segments

308
00:13:33,280 --> 00:13:37,600
that let teams move really fast. It's about maximizing power while minimizing that

309
00:13:37,600 --> 00:13:38,240
proprietary

310
00:13:38,240 --> 00:13:43,120
risk. Right. Considering that combination guaranteed price stability from the self-hosting

311
00:13:43,120 --> 00:13:47,110
option, plus potentially saving, you know, a year of engineering time by using

312
00:13:47,110 --> 00:13:47,920
embedded components.

313
00:13:47,920 --> 00:13:51,680
Here's a final thought, a provocative question for you, the listener.

314
00:13:51,680 --> 00:13:56,400
How would redirecting those resources, the budget saved on volume pricing,

315
00:13:56,400 --> 00:14:01,070
the engineering time saved by embedding instead of building? How could that let you

316
00:14:01,070 --> 00:14:01,600
genuinely

317
00:14:01,600 --> 00:14:05,760
accelerate your core product development next year? What could you build if you

318
00:14:05,760 --> 00:14:06,560
weren't maintaining

319
00:14:06,560 --> 00:14:10,640
messaging infrastructure? That's definitely something powerful to think about reallocating

320
00:14:10,640 --> 00:14:15,200
that focus. Thank you so much for joining us for this deep dive into DittoFeed and

321
00:14:15,200 --> 00:14:16,000
one final thank

322
00:14:16,000 --> 00:14:20,260
you to our supporter, SafeServer. They assist with software hosting and digital

323
00:14:20,260 --> 00:14:21,120
transformation.

324
00:14:21,120 --> 00:14:24,080
You can find out more at www.safeserver.de