1
00:00:00,000 --> 00:00:05,280
Okay, let's unpack this. We are diving into a toolkit today that, well, it seems to

2
00:00:05,280 --> 00:00:05,360
have

3
00:00:05,360 --> 00:00:10,210
really shifted how product engineers think about building software. And actually,

4
00:00:10,210 --> 00:00:10,800
before we really

5
00:00:10,800 --> 00:00:15,670
get started, we absolutely want to thank the supporter of this deep dive. Safe

6
00:00:15,670 --> 00:00:16,640
Server. Safe

7
00:00:16,640 --> 00:00:20,750
Server supports this exploration, handling the hosting side of things for software

8
00:00:20,750 --> 00:00:21,360
like this,

9
00:00:21,360 --> 00:00:27,520
and really aiding in your digital transformation. You can find more info at www.safeserver.de.

10
00:00:28,320 --> 00:00:33,580
So our mission today is to explore PostHog. The goal is, well, pretty simple.

11
00:00:33,580 --> 00:00:34,960
Explain what this

12
00:00:34,960 --> 00:00:39,460
heavily starred open source platform actually is, why it makes this bold claim of

13
00:00:39,460 --> 00:00:40,560
being an all-in-one

14
00:00:40,560 --> 00:00:44,220
solution, and importantly, how it simplifies life for product teams. Especially,

15
00:00:44,220 --> 00:00:44,720
you know,

16
00:00:44,720 --> 00:00:47,600
if you're maybe just starting out in the world of product analytics. And you can

17
00:00:47,600 --> 00:00:48,160
tell it's gaining

18
00:00:48,160 --> 00:00:52,040
serious momentum. I mean, our sources today are straight from their main marketing

19
00:00:52,040 --> 00:00:52,960
pages, sure,

20
00:00:52,960 --> 00:00:58,880
but also their GitHub repo, and that shows, what, 29.8 thousand stars and 2,000 forks.

21
00:00:58,880 --> 00:01:02,230
Wow. Yeah, that kind of traction doesn't just happen by accident. It really signals

22
00:01:02,230 --> 00:01:02,480
they're

23
00:01:02,480 --> 00:01:06,820
solving a, well, a pretty crucial pain point for developers. Absolutely. So the big

24
00:01:06,820 --> 00:01:07,360
picture,

25
00:01:07,360 --> 00:01:12,000
the core idea, is that PostHog aims to be the single source of truth for building

26
00:01:12,000 --> 00:01:12,480
successful

27
00:01:12,480 --> 00:01:17,120
products. It rolls together product analytics, session recording, feature flagging,

28
00:01:17,120 --> 00:01:17,920
A-B testing,

29
00:01:17,920 --> 00:01:22,240
all those separate tools that product engineers usually have to kind of cobble

30
00:01:22,240 --> 00:01:22,560
together.

31
00:01:22,560 --> 00:01:24,480
Right. And one open source bundle.

32
00:01:24,480 --> 00:01:29,040
Exactly. Okay, so here's where it gets really interesting for me. You know, every

33
00:01:29,040 --> 00:01:29,760
tech stack

34
00:01:29,760 --> 00:01:34,240
eventually hits that problem of tool sprawl, right? One service for errors,

35
00:01:34,240 --> 00:01:40,000
another for feature flags, maybe a third for user analytics. Why did PostHog decide

36
00:01:40,000 --> 00:01:40,800
to consolidate

37
00:01:40,800 --> 00:01:45,680
everything? What's the philosophy behind that? Well, what's fascinating here is it

38
00:01:45,680 --> 00:01:46,000
feels like

39
00:01:46,000 --> 00:01:51,280
a core philosophical shift. They actually define PostHog as a product OS, like an

40
00:01:51,280 --> 00:01:52,080
operating system,

41
00:01:52,080 --> 00:01:55,920
but for your product data. A product OS, okay. Yeah, and they recognize that if you're

42
00:01:55,920 --> 00:01:56,480
a developer,

43
00:01:56,480 --> 00:01:59,840
pretty much every decision you make, you know, should I fix this bug? Should we

44
00:01:59,840 --> 00:02:00,240
launch that

45
00:02:00,240 --> 00:02:04,880
feature? It all requires context. The key insight driving this whole thing seems to

46
00:02:04,880 --> 00:02:05,680
be that developers

47
00:02:05,680 --> 00:02:09,120
should operate from the full set of data, not just like a siloed slice of what's

48
00:02:09,120 --> 00:02:10,000
happening inside

49
00:02:10,000 --> 00:02:14,520
their app. Right, we've all felt that pain of disconnected data silos. You know, if

50
00:02:14,520 --> 00:02:14,880
I'm trying

51
00:02:14,880 --> 00:02:19,010
to debug something critical, I need the error log, sure, but I also need to see the

52
00:02:19,010 --> 00:02:20,240
user's click path

53
00:02:20,240 --> 00:02:25,670
and maybe know if they're a paying customer. It all matters. Exactly. So what does

54
00:02:25,670 --> 00:02:27,680
this full set of data

55
00:02:27,680 --> 00:02:32,060
actually mean in PostHog's world? Technically speaking, I mean. It means basically

56
00:02:32,060 --> 00:02:32,640
breaking

57
00:02:32,640 --> 00:02:36,240
down those walls between the different operational bits of the business and the

58
00:02:36,240 --> 00:02:37,200
product engineering

59
00:02:37,200 --> 00:02:41,800
side. So for instance, PostHog is designed to integrate data that happens outside

60
00:02:41,800 --> 00:02:42,560
the application

61
00:02:42,560 --> 00:02:47,570
itself, but still really defines that customer experience. Okay, like what? Things

62
00:02:47,570 --> 00:02:48,400
like financial

63
00:02:48,400 --> 00:02:52,720
data, maybe payments tracked in Stripe, or exceptions captured by a separate error

64
00:02:52,720 --> 00:02:53,680
tracking tool,

65
00:02:53,680 --> 00:02:57,930
or even support tickets logged in something like Zendesk or Salesforce. Okay, wait

66
00:02:57,930 --> 00:02:59,120
a second. If I'm

67
00:02:59,120 --> 00:03:03,620
a developer, that sounds fantastic for making decisions, definitely. But I have to

68
00:03:03,620 --> 00:03:03,840
ask,

69
00:03:03,840 --> 00:03:10,080
isn't consolidating financial data, customer service history, and every single user

70
00:03:10,080 --> 00:03:10,240
click

71
00:03:10,240 --> 00:03:15,840
into one potentially open source platform? Isn't that a pretty significant security

72
00:03:15,840 --> 00:03:15,920
and

73
00:03:15,920 --> 00:03:20,150
maintenance challenge? That's a lot of critical data in one basket. That's a really

74
00:03:20,150 --> 00:03:20,560
important

75
00:03:20,560 --> 00:03:24,210
question, yeah. And it speaks directly to their engineering approach, I think.

76
00:03:24,210 --> 00:03:24,720
Their argument

77
00:03:24,720 --> 00:03:30,110
seems to be that managing one highly secure integrated system is actually less

78
00:03:30,110 --> 00:03:30,560
risky,

79
00:03:30,560 --> 00:03:35,170
potentially, than constantly syncing sensitive data between, say, half a dozen

80
00:03:35,170 --> 00:03:36,160
separate vendors.

81
00:03:36,160 --> 00:03:39,600
Oh, okay. Each with its own authentication, its own compliance quirks. By

82
00:03:39,600 --> 00:03:40,720
integrating these pipes,

83
00:03:40,720 --> 00:03:43,870
they have this data pipelines and warehouse component we can talk about. They

84
00:03:43,870 --> 00:03:44,240
create a kind

85
00:03:44,240 --> 00:03:48,680
of unified identity across the data. I see. Which lets you do things like say, okay,

86
00:03:48,680 --> 00:03:49,040
show me all

87
00:03:49,040 --> 00:03:52,800
users who clicked feature X, had error Y last Tuesday, and submitted a high

88
00:03:52,800 --> 00:03:53,680
priority support

89
00:03:53,680 --> 00:03:58,040
ticket last week. That kind of visibility, well, it allows for much more informed

90
00:03:58,040 --> 00:03:58,880
decisions.

91
00:03:58,880 --> 00:04:03,120
It sounds like the real value isn't just having the tools in one place, but it's

92
00:04:03,120 --> 00:04:04,240
that single,

93
00:04:04,240 --> 00:04:10,730
unfragmented view of the entire user journey from payment to frustration to

94
00:04:10,730 --> 00:04:12,000
actually using a feature.

95
00:04:12,000 --> 00:04:17,920
Precisely. It shifts the focus from just reporting abstract numbers to directly

96
00:04:17,920 --> 00:04:18,480
informing

97
00:04:18,480 --> 00:04:22,400
actual product strategy changes. So we get the philosophy,

98
00:04:22,400 --> 00:04:27,200
single source of truth, unified view. Since it is an all-in-one platform,

99
00:04:27,200 --> 00:04:31,280
let's look at the toolkit itself. But maybe instead of just defining basic terms,

100
00:04:31,280 --> 00:04:35,040
because our listeners probably know what A-B testing is, let's focus on the synergy.

101
00:04:35,040 --> 00:04:38,800
How do these tools actually work together in this unified environment?

102
00:04:38,800 --> 00:04:41,840
That's the critical difference, right? Because in a traditional stack, you might

103
00:04:41,840 --> 00:04:42,960
run an A-B test in,

104
00:04:42,960 --> 00:04:47,600
say, tool A, but then you've got to manually pipe those results over to tool B,

105
00:04:47,600 --> 00:04:48,560
your main analytics

106
00:04:48,560 --> 00:04:51,600
platform, just to see the full impact. Yeah, that's always a pain.

107
00:04:51,600 --> 00:04:56,460
Here, the idea is the tools share the same underlying event data immediately. So

108
00:04:56,460 --> 00:04:56,640
take

109
00:04:56,640 --> 00:05:00,320
product analytics combined with feature flags. Let's say you set up a feature flag.

110
00:05:00,320 --> 00:05:00,560
Maybe you're

111
00:05:00,560 --> 00:05:04,720
rolling out a new checkout button to just 10% of your users. Since the flag is

112
00:05:04,720 --> 00:05:05,360
native to the

113
00:05:05,360 --> 00:05:10,640
platform, that 10% cohort is just automatically tracked by the analytics engine. No

114
00:05:10,640 --> 00:05:11,360
extra setup.

115
00:05:11,360 --> 00:05:16,370
Then, maybe the next day, you decide, hey, let's turn this into a proper experiment,

116
00:05:16,370 --> 00:05:17,280
an A-B test.

117
00:05:17,280 --> 00:05:21,120
You don't have to redefine the cohort. You don't have to re-instrument any code.

118
00:05:21,120 --> 00:05:21,680
The data is already

119
00:05:21,680 --> 00:05:25,880
flowing right into the experiments tool. That allows for immediate statistical

120
00:05:25,880 --> 00:05:27,200
analysis on, say,

121
00:05:27,200 --> 00:05:30,320
conversion rate changes. Okay, that dramatically cuts down on the

122
00:05:30,320 --> 00:05:35,800
operational lag and the engineering overhead, I imagine. What about the tools

123
00:05:35,800 --> 00:05:36,880
focused more on

124
00:05:36,880 --> 00:05:42,080
like product stability, errors and replays? Yeah, look at session replays and error

125
00:05:42,080 --> 00:05:42,560
tracking.

126
00:05:42,560 --> 00:05:46,000
Session replays, for those who haven't used them, are like watching a screen

127
00:05:46,000 --> 00:05:46,960
recording of a real

128
00:05:46,960 --> 00:05:48,880
user session. Right, super useful.

129
00:05:48,880 --> 00:05:52,950
In the traditional model, if a user reports some weird issue, you might see the

130
00:05:52,950 --> 00:05:53,840
error log in tool

131
00:05:53,840 --> 00:05:58,280
A, but you have zero visual context. You're just guessing. With post hog, the idea

132
00:05:58,280 --> 00:05:59,120
is if an error

133
00:05:59,120 --> 00:06:03,360
pops up in the error tracking section, the developer can immediately click and jump

134
00:06:03,360 --> 00:06:04,080
straight to the

135
00:06:04,080 --> 00:06:08,240
session replay that's tied to that exact moment the error occurred. Oh, wow. Okay,

136
00:06:08,240 --> 00:06:08,800
so instead of

137
00:06:08,800 --> 00:06:13,170
trying to reproduce a bug based on just a stack trace, which can be impossible

138
00:06:13,170 --> 00:06:14,320
sometimes, I can

139
00:06:14,320 --> 00:06:18,970
actually watch the user encounter the bug live, see exactly what steps they took,

140
00:06:18,970 --> 00:06:19,840
maybe check the

141
00:06:19,840 --> 00:06:23,900
corresponding network logs right there alongside the replay. That sounds like, well,

142
00:06:23,900 --> 00:06:24,560
like a huge

143
00:06:24,560 --> 00:06:28,600
improvement in debugging time. It absolutely can be. Yeah. And kind of feeding into

144
00:06:28,600 --> 00:06:29,200
all of this

145
00:06:29,200 --> 00:06:33,040
is the data warehouse pipelines capability. This is sort of the heavy lifting

146
00:06:33,040 --> 00:06:33,760
engine behind the

147
00:06:33,760 --> 00:06:37,870
scenes. It's what ingests that external data, we talked about Stripe, HubSpot,

148
00:06:37,870 --> 00:06:38,480
whatever,

149
00:06:38,480 --> 00:06:42,880
and lets you run custom transformations on it. Okay. And critically, it then lets

150
00:06:42,880 --> 00:06:43,680
you send that

151
00:06:43,680 --> 00:06:49,350
enriched unified data stream out to, I think they say 25 plus other downstream

152
00:06:49,350 --> 00:06:50,800
tools. So it ensures

153
00:06:50,800 --> 00:06:55,020
post hoc remains flexible, even if your stack evolves later. That makes sense. Keeps

154
00:06:55,020 --> 00:06:55,280
it from

155
00:06:55,280 --> 00:06:59,170
being too much of a closed box. Finally, we should probably talk about LLM

156
00:06:59,170 --> 00:07:00,000
analytics. You know,

157
00:07:00,000 --> 00:07:04,800
AI powered applications are becoming huge, but they bring this whole new layer of

158
00:07:04,800 --> 00:07:05,440
operational

159
00:07:05,440 --> 00:07:08,720
complexity. How does post hoc handle that? This is where they really seem to be

160
00:07:08,720 --> 00:07:09,520
looking ahead.

161
00:07:09,520 --> 00:07:14,650
For applications using large language models, they're capturing specialized metrics

162
00:07:14,650 --> 00:07:14,960
that are

163
00:07:14,960 --> 00:07:21,520
pretty vital for operations. Things like API call traces, token generation counts,

164
00:07:21,520 --> 00:07:25,920
latency for the model responses, and even the actual cost per query. Oh,

165
00:07:25,920 --> 00:07:27,040
interesting. Tracking

166
00:07:27,040 --> 00:07:32,040
the cost directly. Yeah. It's an essential, quite specialized layer for measuring

167
00:07:32,040 --> 00:07:32,960
the efficiency

168
00:07:32,960 --> 00:07:37,460
and performance of these AI driven products. And it connects that raw engineering

169
00:07:37,460 --> 00:07:37,760
cost

170
00:07:37,760 --> 00:07:42,320
directly to the user behavior metrics you're seeing in the main analytics dashboard.

171
00:07:42,880 --> 00:07:47,070
It feels like a key feature that frankly, a lot of other consolidated platforms are

172
00:07:47,070 --> 00:07:47,440
probably only

173
00:07:47,440 --> 00:07:50,960
just starting to think about. Yeah, that definitely feels ahead of the curve. Okay,

174
00:07:50,960 --> 00:07:52,080
that is a seriously

175
00:07:52,080 --> 00:07:55,180
ambitious suite of tools all bundled together. It almost sounds like the kind of

176
00:07:55,180 --> 00:07:55,920
infrastructure

177
00:07:55,920 --> 00:08:00,400
only, you know, major enterprises could typically afford or manage. So what does

178
00:08:00,400 --> 00:08:01,200
this all mean for

179
00:08:01,200 --> 00:08:05,030
someone just wanting to get started? Is this actually accessible to small teams or

180
00:08:05,030 --> 00:08:05,440
is there

181
00:08:05,440 --> 00:08:10,710
a steep barrier to entry? This is where their open source roots and their pricing

182
00:08:10,710 --> 00:08:11,760
philosophy really

183
00:08:11,760 --> 00:08:15,560
come into play and make a difference. They basically offer two main paths. The

184
00:08:15,560 --> 00:08:16,000
recommended

185
00:08:16,000 --> 00:08:20,790
option is post hog cloud. Right, the hosted version. Exactly. It's engineered for

186
00:08:20,790 --> 00:08:21,200
speed,

187
00:08:21,200 --> 00:08:25,440
reliability, basically zero maintenance for you. And crucially, they offer an

188
00:08:25,440 --> 00:08:26,720
extremely generous

189
00:08:26,720 --> 00:08:31,200
free tier. How generous are we talking here? Like for a startup or maybe just an

190
00:08:31,200 --> 00:08:31,600
individual

191
00:08:31,600 --> 00:08:36,000
developer exploring the platform? We're talking generous to the point where they

192
00:08:36,000 --> 00:08:37,440
state that 98%

193
00:08:37,440 --> 00:08:42,670
of their customers currently use it entirely for free. Wow, 98%. Yep. Every month

194
00:08:42,670 --> 00:08:43,120
you get,

195
00:08:43,120 --> 00:08:47,440
let's see, 1 million events for product analytics, 5,000 session recordings, 1

196
00:08:47,440 --> 00:08:48,480
million feature flag

197
00:08:48,480 --> 00:08:53,920
requests, 100,000 exceptions tracked for errors, and 1,500 survey responses. All

198
00:08:53,920 --> 00:08:54,720
free every month.

199
00:08:54,720 --> 00:08:58,960
Okay. That is a huge operational allowance for a startup or a small team. That's

200
00:08:58,960 --> 00:09:00,560
pretty impressive.

201
00:09:00,560 --> 00:09:04,790
Pricing only kicks in after you hit those limits. Correct. Usage based after the

202
00:09:04,790 --> 00:09:05,680
free tier. Got it.

203
00:09:06,240 --> 00:09:11,440
And what about the pure open source experience? You know, for teams who really

204
00:09:11,440 --> 00:09:13,040
insist on absolute

205
00:09:13,040 --> 00:09:18,080
data sovereignty and want to self-host everything? That option is definitely there.

206
00:09:18,080 --> 00:09:18,720
The ability to

207
00:09:18,720 --> 00:09:24,130
deploy a kind of hobby instance with just a single line of code using Docker on

208
00:09:24,130 --> 00:09:26,000
Linux exists. However,

209
00:09:26,000 --> 00:09:29,240
and they're quite transparent about this too, the source is generally advised that

210
00:09:29,240 --> 00:09:30,080
this setup is

211
00:09:30,080 --> 00:09:35,120
really only recommended up to maybe about 100,000 events per month. Ah, okay. So it

212
00:09:35,120 --> 00:09:36,080
has limitations

213
00:09:36,080 --> 00:09:40,160
at scale. Yeah, if you scale beyond that, they strongly suggest migrating to their

214
00:09:40,160 --> 00:09:40,560
cloud

215
00:09:40,560 --> 00:09:45,360
infrastructure simply because managing the underlying data warehouse click house,

216
00:09:45,360 --> 00:09:50,640
I believe for massive scale, is a really non-trivial engineering task. And well,

217
00:09:50,640 --> 00:09:53,920
they handle that best. Makes sense. Now let's talk about their culture for a second

218
00:09:53,920 --> 00:09:54,560
because this is

219
00:09:54,560 --> 00:09:58,240
often overlooked, but I think it's pretty central to their whole appeal, especially

220
00:09:58,240 --> 00:09:59,120
to developers.

221
00:09:59,120 --> 00:10:02,380
They don't just open source their code. Right. They seem to open source their

222
00:10:02,380 --> 00:10:03,280
entire company.

223
00:10:03,280 --> 00:10:05,910
Wait, what do you mean? Like their internal processes? What does that actually

224
00:10:05,910 --> 00:10:06,320
involve?

225
00:10:06,320 --> 00:10:11,280
Well, it's pretty extreme transparency. They open source their entire company handbook.

226
00:10:11,280 --> 00:10:16,080
It details their strategy, how they make decisions, their ways of working, internal

227
00:10:16,080 --> 00:10:16,640
processes.

228
00:10:16,640 --> 00:10:22,420
Seriously, their strategy docs are public. Yeah. And look, it's probably not just a

229
00:10:22,420 --> 00:10:23,280
gimmick. It

230
00:10:23,280 --> 00:10:27,260
seems to build this profound trust with the developer community who aren't just

231
00:10:27,260 --> 00:10:27,600
users,

232
00:10:27,600 --> 00:10:31,600
but often contributors too. It's like a powerful statement. Look, if we're this

233
00:10:31,600 --> 00:10:32,320
transparent about

234
00:10:32,320 --> 00:10:35,920
how we operate internally, you could probably trust us to handle your mission

235
00:10:35,920 --> 00:10:36,640
critical data

236
00:10:36,640 --> 00:10:41,680
responsibly. That's bold. And I guess that transparency extends directly to their

237
00:10:41,680 --> 00:10:42,080
pricing

238
00:10:42,080 --> 00:10:46,410
philosophy too, which sounds like a pretty sharp contrast to standard sauce

239
00:10:46,410 --> 00:10:47,280
practices.

240
00:10:47,280 --> 00:10:51,440
Absolutely. Their pricing is completely usage based, like we said, and they have an

241
00:10:51,440 --> 00:10:51,920
explicit

242
00:10:51,920 --> 00:10:55,660
no sales call approach. You don't have to talk to anyone to get started or figure

243
00:10:55,660 --> 00:10:56,320
out costs.

244
00:10:57,040 --> 00:11:02,710
Nice. You can calculate your exact cost based on totally transparent per unit

245
00:11:02,710 --> 00:11:03,760
pricing, like that

246
00:11:03,760 --> 00:11:09,180
zero, zero, zero, zero, zero, five per event number after the free tier limit.

247
00:11:09,180 --> 00:11:09,760
There are no hidden

248
00:11:09,760 --> 00:11:14,700
tiers, no complex enterprise negotiations just to figure out what you'll owe. They

249
00:11:14,700 --> 00:11:15,520
explicitly aim

250
00:11:15,520 --> 00:11:19,410
to be the cheapest option at scale. And this radically transparent model is kind of

251
00:11:19,410 --> 00:11:19,760
how they

252
00:11:19,760 --> 00:11:23,520
try to prove it. Okay. That's refreshing. Finally, let's just circle back quickly

253
00:11:23,520 --> 00:11:24,480
to the future.

254
00:11:24,480 --> 00:11:28,630
Beyond the LLM analytics tool they already offer, what are their teams apparently

255
00:11:28,630 --> 00:11:29,440
focused on in

256
00:11:29,440 --> 00:11:33,420
terms of integrating AI within the platform itself? Well, the roadmap seems to

257
00:11:33,420 --> 00:11:34,160
suggest they're

258
00:11:34,160 --> 00:11:38,570
shifting the goal beyond just measurement towards more active automation. They're

259
00:11:38,570 --> 00:11:39,200
apparently working

260
00:11:39,200 --> 00:11:43,330
on AI features to automate some of the more monotonous analysis tasks, maybe

261
00:11:43,330 --> 00:11:44,000
summarize

262
00:11:44,000 --> 00:11:48,890
complex user journey information automatically. Okay. And perhaps more ambitiously

263
00:11:48,890 --> 00:11:50,160
integrating AI

264
00:11:50,160 --> 00:11:54,720
into the actual development workflow. Like having the platform eventually suggest

265
00:11:54,720 --> 00:11:55,440
or maybe even make

266
00:11:55,440 --> 00:11:59,540
code changes to fix bugs, it identifies automatically. Yeah, definitely an

267
00:11:59,540 --> 00:12:00,800
evolution from just being a

268
00:12:00,800 --> 00:12:04,350
data collector to potentially be more like a product co-pilot. That's quite a

269
00:12:04,350 --> 00:12:05,280
vision. So I

270
00:12:05,280 --> 00:12:09,240
guess the key takeaway here is that this isn't really just one tool or even just a

271
00:12:09,240 --> 00:12:09,920
collection

272
00:12:09,920 --> 00:12:15,580
of tools. It's more like a unified, very open and incredibly transparent ecosystem

273
00:12:15,580 --> 00:12:16,400
designed to give

274
00:12:16,400 --> 00:12:21,190
product engineers that single source of truth, hopefully eliminating some of the

275
00:12:21,190 --> 00:12:22,160
guesswork and

276
00:12:22,160 --> 00:12:26,120
maybe even the security risks that come from having all these disparate data

277
00:12:26,120 --> 00:12:27,760
sources. Indeed.

278
00:12:27,760 --> 00:12:33,730
And maybe for a final provocative thought, the sources mentioned their unique

279
00:12:33,730 --> 00:12:34,800
culture,

280
00:12:34,800 --> 00:12:38,000
including this one time they apparently sent customers a floppy disk that turned

281
00:12:38,000 --> 00:12:38,320
out to be

282
00:12:38,320 --> 00:12:42,950
a rickroll. Okay. Which is fun, sure. But underlying that is that transparency we

283
00:12:42,950 --> 00:12:43,680
talked about sharing

284
00:12:43,680 --> 00:12:47,680
their strategy, their sales manual, their inner workings. That's what feels really

285
00:12:47,680 --> 00:12:48,400
foundational.

286
00:12:48,400 --> 00:12:52,880
And the question for you, the listener might be, if a company is that open about

287
00:12:52,880 --> 00:12:53,680
how they operate

288
00:12:53,680 --> 00:12:57,140
internally, how much does that influence your trust when you're deciding whether to

289
00:12:57,140 --> 00:12:57,680
build your

290
00:12:57,680 --> 00:13:01,530
own mission critical product on their platform? That openness, maybe it isn't just

291
00:13:01,530 --> 00:13:02,160
a feature,

292
00:13:02,160 --> 00:13:05,870
maybe it's a kind of security and confidence guarantee in itself. That's a great

293
00:13:05,870 --> 00:13:06,240
question

294
00:13:06,240 --> 00:13:10,090
to leave you with. Thank you for joining us for this deep dive into PostHawk. And

295
00:13:10,090 --> 00:13:10,640
once again,

296
00:13:10,640 --> 00:13:14,960
a big thank you to SafeServer for the support of this deep dive that helps you with

297
00:13:14,960 --> 00:13:15,280
digital

298
00:13:15,280 --> 00:13:22,320
transformation and hosting of software. More information can be found at www.bigsafeserver.de.

299
00:13:22,320 --> 00:13:23,360
We'll see you next time.