Building Chirm: A calmer way to share information across a company

05 Mar 2026

Introduction

In many companies, important operational updates are spread across too many places. Some things land in chat, some in email, some are mentioned in meetings and some are simply learned by accident. This gets especially messy once the company grows beyond a few tightly connected teams, or when remote work becomes normal, as it did especially since Covid.

Chat tools are great for fast back-and-forth communication, but they are not necessarily a good place for information that should remain visible, easy to catch up on, and available to the right people later on. A release update, a process change, a location-specific announcement or maybe a very helpful tool that was built in a team should not have to drown in a river of chat messages or Teams teams.

This is one of the reasons why I started building Chirm, an internal communication platform for calmer, asynchronous company-wide updates. The project is available at https://chirm.app/en.

A mildly amusing detail is that this did not start as that grand product plan. At first, it was mainly a playground for microservice architecture and I thought that a microblogging-style application would be a good idea for experimenting with service boundaries, timelines, events and the general joys and pains of distributed systems. Only while building it did I notice that the thing I was building maps surprisingly well to solving a real communication problem inside companies. That is the point where the project started turning from a technical playground into what Chirm is now.

In this article I want to describe the problem Chirm is trying to solve, what kind of system I ended up building and a bit of the technical setup behind it. I may come up with some more technical articles later.

Setup

The basic observation behind Chirm is simple: Many companies do not have a good calm, asynchronous place for the exchange of information.

There are of course many tools around already. Slack and Microsoft Teams are widely used, but they are primarily optimized for collaboration, direct interaction and quick exchange. That is useful, but it also creates a certain mode of communication where everything competes for immediate attention, the last chat message wins. Important updates can easily be buried under ongoing conversations, side discussions, quick questions and the usual background noise of daily work.

At the same time, alternatives on the more social-intranet side often try to do many things at once. That can be useful too, but it also increases complexity.

What I wanted instead was something much narrower: One central place for company communication, built around a personal timeline, where relevant updates can be read asynchronously, reacted to and discussed without creating the feeling that one has to constantly watch a chat window. Basically a social microblogging service inside a company.

And I came up with the core principle that guides the development: The user’s time is precious, do not steal it.

This also means that Chirm is not supposed to replace every communication or collaboration tool inside a company. It is not a project management system, not a wiki and not a general-purpose chat tool. The goal is much more focused: Provide a clean channel for internal company communication that remains readable and useful as an organization grows.

Typical examples that should go over Chirm would be company-wide operational updates, release notes for internal teams, process changes, announcements from leadership, updates for specific departments or locations, and compliance-relevant information that should clearly reach the correct audience. But it should also work for smaller, useful things that normally stay trapped inside one team. A team might build a small internal tool, automate a repetitive task, improve a workflow or discover a useful practice. In many companies, that kind of progress remains local because nobody outside the team ever hears about it, especially since remote work increased the the coffee machine encounters do not happen that often anymore. In Chirm, sharing that should be as easy as writing a short post, so that other teams can react, comment and potentially adapt the idea for their own work.

This is where a timeline-oriented model becomes interesting. Instead of forcing all communication into chat threads or emails, updates can be posted into a structured shared space and consumed when people actually have time for it. And for the really important things, there are mechanisms that allow you to request confirmation, which also makes it a very natural fit for areas like QM.

What did we do?

From the beginning, I wanted Chirm to feel closer to a microblogging platform than to a classic enterprise chat tool, because the goal was not only to distribute important information, but also to make useful work inside a company more visible across team boundaries.

That means a few things. A post is the central object. It can belong to a group, have a topic, receive replies and reactions and remain visible in a timeline. The timeline itself is the main interface. Ideally, most of the daily interaction with the system happens there. Users should not need to jump through ten different menus to understand what is going on or to look into various chat channels or Teams teams to find something.

This also means the system should support both broad and restricted visibility. Some updates are relevant for everyone in a company, while others only make sense within a department, team or location. Therefore group handling and access control are part of the core model.

Another requirement was that the platform should work well in a multi-tenant setup. Chirm is meant to be used by different organizations, each with their own users, groups, permissions and data boundaries. So tenant separation was very important.

On the product side, the first goal was to make posting and reading updates feel straightforward and low effort. A user can create a post, assign it to a group or add a topic, and others can read, react and reply. The timeline then acts as the central view where relevant items come together. This is intentionally simple.

The result is a system where the same basic model can cover different scenarios. A leadership update, a team announcement, a release note, a department-specific operational notice or a short post about a useful internal tool all use the same underlying mechanism. That matters because products become confusing quite quickly when each use case feels like a separate application.

To support all of this technically, the backend was split into services with clearly separated responsibilities, without over-complicating things. There is an API gateway in front of the whole system, an authentication layer that supports SSO and identity providers, and behind it several domain-specific services. For example, posts are handled by the post service, while timeline generation is handled by a timeline service.

I only want to sketch the architecture here at a high level. I will go into more detail about the backend design and the reasoning behind specific architectural choices in a later post. The main point I want to make here is that the service structure follows the communication model quite directly. Writing and retrieving posts, generating timelines, searching content, sending notifications and handling tenant context all have different requirements.

It also supports AI summaries, to help users get a quick overview of activity in their timeline. This becomes more useful once a timeline grows denser or when people return after being away. I wanted summarization to be a distinct capability in the architecture rather than something mixed awkwardly into the rest of the system.

Because this is built for companies and large enterprises, tenants and groups are treated as first-class concepts from the start. Tenant handling determines which organization a user belongs to and what data context is active. Groups define smaller visibility domains inside that tenant. This is what makes it possible to support both broad communication and more focused internal channels without turning everything into one giant company-wide feed, and it is very easy to build company structure into the message flow structure.

The product philosophy and the architecture are therefore connected quite directly. If the goal is calmer communication, the system needs predictable timelines, good search, reliable notifications, clear visibility rules and a user interface that does not constantly fragment attention.

Summary and discussion

Chirm started from a fairly ordinary observation: Companies often lack a good place for operational communication that is visible, structured and not overly noisy.

The default answer is often to use the tools that are already there, especially chat. That works up to a point, but it also creates a mode of communication where important updates are mixed with everything else and easily get lost.

But the issue is not only that important company information gets buried. Another problem is that useful work often stays invisible outside the team that did it. A small internal tool, an improved workflow, a practical script or a process improvement may be very valuable to others, but in many organizations nobody hears about it unless it happens to come up by chance. That means useful ideas stay local when they could have spread.

This is one of the things Chirm is meant to improve. It should not only support structured top-down communication, but also make it easier for teams to share useful things with the rest of the organization in a lightweight and visible way. A short post should be enough to make others aware, let them react, ask questions and reuse what is relevant for them.

Instead of trying to replace every existing tool, Chirm focuses on asynchronous company communication through a simple timeline-based model. The technical design follows from that goal. It should make important updates easier to find, but it should also help ideas, tools and practices travel further across the company.

There is of course still a lot of room for improvement. Internal communication is one of those domains that looks simple at first, but it easily turns into a mess. Building a system that allows communication to remain clear, relevant and pleasant across different teams and organizations is the harder part.

There is also a broader product question underneath all of this. Many software tools optimize for engagement, speed and constant activity, especially classical social media. But for companies this is often the wrong optimization target. Constant noise costs time, attention and therefore money. What matters more is that the right people get the right information at the right time, and that useful knowledge does not remain trapped inside isolated teams. This is what I want to achieve with Chirm.

Next Steps

The immediate next steps for Chirm are not about adding more and more features, but about showing what this communication model can do in practice, both for important operational updates and for lightweight sharing across teams.

For that I continue improving the experience around targeted updates, making it easier to curate relevant information, expanding the document-sharing side and refining the timeline experience further. It also means validating the product in realistic organizational settings.

The overall direction is clear: Building a system that helps companies communicate important things clearly, without adding even more noise to the day.

If you want to see the current product direction or try the demo instance, you can find Chirm at https://chirm.app/en.

Screenshot of Chirm

⇐ Back