How We Ended Up With a Distillery at HappyHQ (And Why Naming Things Is Underrated)

22 April 2025

Editorial note: This post is from the early days of HappyHQ. Some of the ideas and details have since evolved, but these initial thoughts shaped how we think, so we're preserving and sharing them as written.

Every now and then, a name sticks.

HappyHQ felt like that from the start. (There’s a great post on the story behind the name, if you’re curious.)

This is also a story about naming, with a twist. These names were never meant to leave our codebase. What started as a routine effort to name internal components turned into something much more useful.

One thing's for sure...we didn't set out to build a distillery.

When we started building HappyHQ, we were focused on helping teams work better together. As founders writing code and debating features, we were just trying to name things clearly so we could stay on the same page and keep shipping.

But somewhere along the way, as we tried to name each part of the system, and make those names fit together, we found a metaphor that just worked. One metaphor led to another. Before we knew it, we had a fully-formed landscape: springs and falls feeding streams, waterwheels turning, and yes, a distillery.

This accidental metaphor quickly became something more valuable—a mental model that brought clarity not just to our code, but to how we think about, talk about, and build HappyHQ. It gave us language people could relate to, something that made the moving parts of the product feel more intuitive.

And now that we have it, we want to share it. Not just because it’s fun to picture (though it kind of is), but because it’s useful. It creates clarity. And if you’ve ever tried naming anything in a layered system, you know how rare that is.

This is the story of how we named our way to a distillery. And a few other things too.

Why naming matters

Naming is how we make sense of the world. It’s one of the first things we do when a child is born. Pets, storms, stars, cities. We name what matters, because names make things easier to communicate.

Think about how we navigate our world through names. We don't say "that celestial body approximately 93 million miles from Earth", we say "the Sun." We don't reference "that body of water between North America and Europe", we say "the Atlantic." Names simplify complexity. They create shared reference points.

In our daily lives, names serve as cognitive shortcuts that make communication possible:

"Meet me at Central Park" works because we all know what "Central Park" means.

"Super Bowl Sunday" immediately communicates both an event and cultural moment

"The Renaissance" captures centuries of cultural evolution in two words.

Without these names, our conversations would collapse under the weight of descriptions and qualifiers. When something lacks a name, it exists in a kind of limbo—fuzzy around the edges, difficult to grasp, nearly impossible to discuss without confusion.

But a name gives it a home. A reference point. A foundation. The moment something has a name, even a temporary one, it gets easier to see, talk about, and build around.

In product development, naming is often treated as an afterthought, something to tackle once the feature is built or when marketing needs a label. This is often a missed opportunity.

Naming isn't just about labeling what you've already created. It's a tool for shaping what you're building while you build it.

Effective names transform how teams think and build:

When Facebook named their internal performance monitoring system Scuba, it wasn’t just clever, it gave engineers a way to imagine diving deep into data, surfacing insights from beneath the noise.

When Airbnb named their animation system Lottie, it transformed a technical tool into something approachable, memorable, and easy to talk about, especially across teams that don’t share the same vocabulary.

When Netflix created Chaos Monkey, they took a sophisticated infrastructure tool and gave it a playful name, one that captured its essence while making it less intimidating and easier to understand.

The right name invites collaboration, reduces friction, and creates clarity. But names don’t just describe what you’ve built, they can shape how you build it.

Call something a "notification configuration module," and it becomes a technical checkbox on a project plan. Call that same feature "Mission Control," and suddenly it's a vital command center demanding thoughtful design.

Even everyday features benefit from clear naming. A feature described as "that area where users can see all their recent activity and what they might have missed" becomes simply "The Feed"—focused, tangible, discussable.

Names aren't just labels. They're foundations for shared understanding. At HappyHQ, this foundation started simply, with a name so intuitive it (eventually) shaped everything that followed.

It all starts with a Stream

Streams aren’t where this naming story begins, but they’re so central to this story that it’s worth starting there.

Streams were always meant to be public. They’re a foundational feature. Users create Streams directly in the UI. And from our earliest conversations, the name just felt right. It clicked. There was something intuitive about it. Something that captured exactly what we were trying to build. We loved the idea of a continually flowing stream. A stream of thought, or even a stream of data.

Sure, Streams are a little like channels on Slack and topics on X, or even threads on Reddit. Creating defined spaces for related ideas is a familiar and effective pattern. It shows up in many of the tools we use today.

But we were drawn to the name "Streams" because it described the behavior we wanted to see from these features. Unlike channels, streams aren't something we expect folks to tune into. They don't need to be watched.

Most collaboration tools today inadvertently create “snoops”—people compulsively checking every channel and thread out of FOMO or a need for information. We’ve all been that person, and we’ve all worked with them. It’s exhausting, but our tools reward this behavior with dopamine-triggering notifications and the pressure to stay current.

Streams offered a better metaphor. In nature, streams don’t demand attention. They invite interaction on your terms. You dip in when you need to cool off or refresh. No pressure to stay immersed. No snoops constantly monitoring every ripple. The stream keeps flowing whether you’re there or not.

That’s exactly what our Streams do—thoughts, data, files, and conversations all flowing through a shared workspace. They’re constantly moving, carrying ideas and information throughout HappyHQ. Not demanding constant attention but always available when needed.

So, we have Streams.

Users can add to those Streams, creating what we call Entries. But then something kind of magical happens behind the scenes: HappyHQ creates Memories from those Entries.

These Memories are visible directly in the Stream. But they also live beyond it, searchable across the workspace, ready to surface and use whenever and wherever they're needed.

But what should we call the critical functionality that takes Entries and turns them into Memories? It wasn't a Stream, an Entry, or a Memory. If anything it was the bridge between them, and it needed a name in our codebase.

We tried simple, descriptive terms: extractor, enricher, parser. Each felt too narrow, too mechanical, or too bland. They also weren't particularly distinctive. We would do each of those things in many different places in our codebase.

We landed on Cortex. It's the part of the brain associated with processing memories, which aligned perfectly with what we were building. We had already been thinking about HappyHQ as a "shared brain" for teams, so Cortex became our digital version of the system humans use to create memories from everyday experiences.

We even wrote this description:

Our memory engine. Inspired by the cerebral cortex in the brain—the region responsible for higher thought and memory. Observes activity in the Streams, and selectively encodes what's meaningful into long-term Memories. Memories are structured, contextual, and durable. They form the basis for everything downstream.

This felt like a strong choice that aligned with what we were building. If we're honest, it was a bit technical, but since this was exclusively an internal name for our codebase we weren't overly concerned.

It wasn't until we needed to name a similar piece of functionality where we started to question whether the Cortex had staying power.

And then came Digests.

Streams are flowing, Memories are being created. Enter the Digest.

Digests are your new best work friend. Or at least, that’s the idea. They help you focus on what matters. They pull meaningful Memories out of the stream and transform them into something timely and useful: a summary, a nudge, an insight. Delivered when and where you need it. No more FOMO. No more scanning every channel, email, or app to figure out what you missed.

But Digests created new naming challenges. There's the digest itself (what users see), how it's defined (the settings), how it's processed (the job), and how its outputs are consumed (the delivery). This created a lot of surface area for confusion. We tried to address it with clearer phrases: "digest instance," "digest definition," "digest job." Technically, this worked, but it felt heavy. Robotic even. Like we were trying to explain dinner with database terminology.

Once again, we needed a name (at least for our codebase). Something for the functionality that powered the engine behind Digests. And we wanted it to sit comfortably next to Cortex in the mental model.

We ended up on Pons, another part of the brain. Here was our initial description:

Our digest engine. The bridge between memory and meaning. Based on the biological pons, which connects the cortex to the rest of the brain and regulates signal flow. Takes Memories from the Cortex (plus system settings, preferences, and other context) and transforms them into structured digest material. Pons is not the digest itself—it's the processor that prepares information to be shared or surfaced. Works quietly but critically, shaping what gets through and how it's framed.

Technically correct. It handled relay and signal. It fit… on paper. But it didn’t feel right. It didn’t explain itself. And it didn’t help the team talk about what it actually did.

While researching the human brain for alternatives to "Pons," we considered names that didn't play as nicely with the Cortex metaphor. We wanted something cohesive, but this was a codebase-only name after all. One of those alternatives was the Distillery. We initially discounted it to maintain a single mental model, but the seed had been planted. And we couldn't shake it.

“Distillery” just worked. Because that’s exactly what a Digest is—a distilled view of what matters, from everything flowing through your workspace. All the raw, messy context gets boiled down into something readable, relevant, and useful.

The realization hit in one of those back-of-mind moments. You know the ones, when you're not actively thinking about a problem, and suddenly the solution just sort of appears. For us that was the marriage of Distillery and Streams. Distilleries are fed by water from streams. That flow is essential to the process. The two concepts weren't just compatible; they were meant to be paired.

A Distillery was immediately practical in a way "Pons" never was. When someone asked "what does this part do?" we could say "it's the Distillery — it takes everything flowing through the Streams and concentrates it into something more valuable." No neuroscience degree required.

“Distillery” wasn’t just a better name. It gave us a new way of seeing the system. And suddenly, the metaphor began to unfold.

Seeing the whole picture

We already had the Stream. Now we had the Distillery, sitting downstream, turning Memories into something more digestible. So we took a step back and looked at the whole system again — through this new lens.

That’s when the next two pieces clicked. We had been talking about "manual versus programmatic sources" for a while. Useful concepts, but awkward phrases that never quite rolled off the tongue. We needed better language and our new landscape made the choice seem rather obvious.

• The Spring for manual input: human-added thoughts, links, uploads. Intentional and direct.
• The Falls for programmatic input: automations, integrations, incoming email, webhooks. Automated, high volume, and always-on.

They both feed the stream. They both scale naturally. And they seemed to capture exactly what makes these two methods different. No more clunky technical phrases. Just a simple, visual model that made immediate sense.

With those pieces in place, the whole scene started to come together. You could actually start to picture it. A Stream cutting across a valley, fed by The Falls and The Spring, flowing toward the Distillery.

It was time to replace the Cortex. Our brain metaphor felt increasingly out of place as our landscape metaphor came to life.

The Cortex's replacement came from actually picturing the scene. We imagined the Stream flowing left to right. The Distillery sitting calmly downstream. And something, some kind of structure, working quietly in the middle.

What sits naturally in a stream? What draws value from the current without interrupting it?

We saw the answer first: a waterwheel.

Waterwheel mills have been turning flowing water into useful outputs for thousands of years. They sit directly in the stream, powered by the current, extracting value without interrupting the flow.

And yes, we liked the alliteration too. The Memory Mill and the Digest Distillery satisfied that part of our brain that craves symmetry.

The Mill felt right on every level. It's powered by the Stream. It doesn't stop the flow—it works with it. And just like a traditional mill turns grain into flour, our Mill turns flowing Streams into structured Memories.

The Cortex was officially out.
The Mill was in, with its waterwheel spinning in the Stream.

The HappyHQ Landscape

We didn't set out to create a landscape, let alone a metaphor. We just needed to name parts of our codebase. But as this landscape took shape it has helped us see the system as a whole. The parts no longer floated in isolation. They connected. And more importantly, it gave us a way to think. Not just about how our system works, but about how it feels.

But for now, we just wanted to show you the HappyHQ landscape that we picture when we close our eyes. We'll dive deeper into each part of the landscape in future posts.

The Falls: Programmatic data cascading from webhooks and integrations, automated and always-on

The Spring: Manual contributions bubbling up from human activity, intentional and thoughtfully placed

The Stream: Where everything converges, carrying ideas and information in perpetual motion

The Mill: Working steadily mid-stream, its waterwheel turning raw content into enriched Memories

The Distillery: Sitting quietly downstream, concentrating what matters most into crystal-clear Digests

If you look closely, you might even spot an owl perched in the trees, quietly observing the whole operation. But we'll save that story for another time.

The power of names

We started this story with a simple truth: names make things easier to communicate. We end it with a deeper one: great names make things easier to understand.

It's easier to talk about a stream than a pipeline. Easier to picture a mill than a memory parser. And much easier to explain a distillery than a digest processor.

The best part? We didn't plan any of this. We just needed names clear enough to keep shipping. But somewhere along the way, those codebase-only names became something more—a shared vocabulary that explains itself. And when a system explains itself, it’s easier to understand, easier to evolve, and easier to believe in.

Now we have more than a system that works. We have a way to talk about what we’re doing — and why it matters. One with a flowing stream, a spinning waterwheel, and a quiet distillery in the valley.

If you're working on something abstract or complex, and you're struggling to talk about parts of it clearly — try finding your stream. See where it flows. And maybe build a little mill of your own.