We didn't build the chat

Inside the Build · Part 2 of 4

By Miles Sellyn, VP of Partnerships

One of the telltale signs of an engineering team that is talented, but lacks sharp product thinking? They insist on building absolutely everything themselves.

Bell curve meme: both ends say leverage 3rd party services, the middle says build every service yourself

Probably the most significant engineering decision we made while building beehiiv’s Community feature was to leverage a tool called Stream for the chat functionality.

Real time chat is the hardest problem in a community product, because it has dozens of underlying features. Presence, delivery guarantees, unread state, pagination that behaves when somebody scrolls up through four months of history on a bad connection. It is also, and this is the part that matters, completely undifferentiated. Nobody in the history of software has switched platforms because one company's read receipts were more thoughtfully engineered.

So aspects of beehiiv’s Community run on Stream underneath. And it does not look, feel, or behave like a product with somebody else's chat bolted onto it. Why? Because engineering teams with sharp product minds (like I mentioned above) know where to draw the lines around integrations like this.

What you’ll find in today’s issue:

Why "where does it live" is such a crucial question
The type of line that runs through the middle of a feature, not around it
How we used a third party for chat without feeling like it
Three questions for finding your own seam

Before you build it, you should decide where it goes

I know that you, devoted reader, remember last week when I said question six was getting its own issue. Here it is! I deliver on my promises! Vote for me!

Before a single component of Community was designed, we had to figure out where it was going to sit. There were three possible answers, and they had pretty big implications in terms of what type of product it was going to be.

Option A - It could live under a publisher’s existing website header as another page, which is cheap and makes Community feel like a section of a website.

Option B - It could be standalone with its own navigation, which makes it a destination and carries a lot of cost implications, not to mention friction for a user.

Option C - It could sit on a subdomain or in a subfolder, which sounds like meaningless and simply a URL preference…until you think about SEO, session handling, and what happens to a reader who is logged into one and not the other.

Our first exploration kept the website header and tucked Community navigation underneath it. beehiiv wanted something more standalone. Where we ended up was Community with its own sidebar navigation, rendering newsletter posts inside it, with a clear route back to the site.

This kind of thing feels small, but it actually determines what gets rendered where, what needs authentication, what the URLs look like forever, and whether a reader’s experience feels like one product or two.

This is how the integration surface question manifests in practice. This tends to come up a ton in internal tool development. Does the new tool live inside an existing tool (intranet, etc.), next to it, or as its own destination behind single sign on?

A nice way to derisk this is to sketch the same thing in three locations before you commit to one.

The seam runs through the feature, not around it

So - back to the chat feature!

Build versus buy usually gets argued as a whole feature, which is why it turns into a stalemate. The architecture team wants to own it because owning it is the job. Finance wants to buy it because buying it has a number attached. Both are arguing about what they perceive as an indivisible lump…but what if I told you the lump is not indivisible.

What if I told you there was no indivisible lump meme

Almost every feature/product has two halves. There is the half your customer will never see, which is infrastructure, and there is the half they touch, which is what they perceive to be as your product. The seam runs between them, through the middle of the feature. These seams are somewhat arbitrary…or if not arbitrary, adjustable.

So in this case, our team adopted Stream's message list, which meant things like: inheriting scroll behavior, pagination, and read tracking, all of which are genuinely hard and none of which any publisher will ever notice working correctly.

But then we overrode every visible component with our own. We never loaded a single line of Stream's CSS. Each publication's brand colors get piped through, so the chat wears the publisher's brand the same way the rest of Community does.

The resulting product feels and reads as native because the only borrowed part is the plumbing.

The most common way this mistake surfaces is not buying too much or building too much. It is drawing the line from a product standpoint around the whole feature instead of through it, which is a forcing function in choice between owning something that does not matter and outsourcing something that does.

Finding your own seam, #seamteam

Three quick questions to ask that are super helpful as you consider implementation of this, and they work on basically any feature on your roadmap.

Would a customer ever notice this working correctly? If the honest answer is no, it is infrastructure. Chat delivery, file storage, payments, transactional email, search indexing, video encoding. Buy it. Owning it is just genuinely not that valuable, as it is not differentiated.

If a competitor had the identical version of this, would we lose anything? If no, buy! If the answer is that you would lose the thing your product is actually for, build it, and build it properly.

Can we replace the interface without replacing the engine? This is the one people skip, for the most part. beehiiv can swap the visible layer of chat without renegotiating a vendor relationship, because the interface was never the vendor's. If the tool you are buying insists on rendering your product interface for you, you did not buy infrastructure. You rented a product and slapped your logo on it.

Take 5 minutes to ask these questions across the feature list you are staring at right now. My experience is that roughly a third of what teams plan to build is infrastructure they have talked themselves into owning, usually because a smart engineer correctly pointed out that it is buildable. But engineers think everything is buildable!

The version of this I like most is that buying the boring half is what frees you to be obsessive about the half that matters. beehiiv did not save time by using Stream and then spend it elsewhere. They spent it on making chat feel like beehiiv, which is how great products differentiate themselves.

That's it for today. If you found this valuable, forward it to the engineer on your team currently writing a document about why you should build your own real time infrastructure. Be gentle with them, they are having a nice time.

Next Thursday, devoted reader, we will get into build criteria, and specifically what happens when your AI tools can generate more work than your team can properly evaluate.