At a construction company where I worked as IT manager, communication was fragmented across three channels that never talked to each other.
Seven people in the office. Around twenty workers and laborers across active construction sites, four or five on any given site at a time. Messages on personal WhatsApp numbers. Phone calls. The occasional email nobody read in time. Site photos sent to random personal chats. The office never knew what was happening on site unless someone picked up the phone.
The standard answer would have been Slack or Microsoft Teams. I went with Mattermost.
Why Mattermost
Three reasons.
Self-hosted. The company's data, site photos, project updates, internal decisions, stays on a server I control. Not on Slack's infrastructure, not on Microsoft's. For a small business that was a deliberate choice, not a compliance checkbox.
One nuance worth knowing: push notifications for the official mobile apps are relayed through Mattermost's hosted push service, which forwards them to Apple and Google. The message content stays on my server, the notification metadata does not. Fully self-hosted push means compiling your own mobile apps with your own push proxy, which was more complexity than a company of this size needed. For this deployment, the trade-off was acceptable.
The mobile app works. Construction workers are not going to open a browser on their phone. The Mattermost Android app is fast and sends push notifications reliably. That was non-negotiable.
The desktop client behaves well on KDE Plasma. Tray icon works, notifications integrate cleanly, no visual glitches. Relevant because KDE is the Linux desktop I deploy.
The deployment
I installed Mattermost on an existing VPS that already hosted other internal services, with PostgreSQL as the database and Nginx in front for TLS. The official docs cover this well. What mattered more was what came after the install.
I created the team and built a minimal channel structure: one general channel, one per active project, one for the office, one for site updates.
I kept it flat on purpose. Over-organizing before people start using the tool is a waste of time.
Training the office and the site supervisors
The office staff took about thirty minutes each. Channels instead of group chats clicked quickly once I showed one real example.
The workers took longer, not because the app was difficult, but because structured communication was new to them. What worked was framing it simply: the work WhatsApp, but owned by the company, and nothing gets lost.
I ran one group session on site with the supervisors' phones. Showed them how to post a photo to the right project channel. They then handled it with their own crews. That was most of the training.
Then I left them alone.
What actually changed
Before Mattermost, the only way to know what was happening on site was a phone call. The office would ask, someone would answer, information would get lost in translation.
After the deployment, the geometra (site surveyor) could open the project channel and see what the capocantiere (site foreman) had posted an hour ago. The owner could check site progress without calling anyone. The office had context when clients called with questions. Everyone was looking at the same information at the same time.
Nobody asked for this explicitly. It emerged from having one place where site updates actually landed.
What happened after I stopped managing it
A few weeks in I checked the channels. The team had reorganized things themselves. Created channels I hadn't set up. Developed their own conventions. One site supervisor started pinning important updates so the office could find them later.
I had not asked for any of that.
If the tool is solid and the initial training is honest, people adapt it to their actual workflow without hand-holding.
Two things I'd tell anyone deploying this
Keep the initial channel structure minimal. Three or four channels maximum at the start. Let the team build it out once they understand how they actually communicate.
Plan for storage before you go live. Construction sites generate a lot of photos. Twenty workers with phones and something visual about their work will fill a disk faster than you expect. Size the VPS accordingly, set file size limits from day one, and decide early what happens to old project channels: archive them, keep the files, and make sure your backup covers both the database and the file store.
I no longer work at that company. The setup stayed, which is the part I care about. I carry the same approach into my current work at Zerolock, where Mattermost is part of the standard stack I deploy for clients who need internal communication without handing data to third-party platforms.
Top comments (0)