Should I vibe code
Self-host team chat with channels, threads, search, and integrations
You can self-host the real thing this afternoon. Rebuilding it only makes you the one who gets paged.
?
Their verdict, the Professional price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The odd thing about this one is that the product is already free. Mattermost is open source and self-hostable, and the paid tiers mostly buy SSO, compliance tooling and somebody to phone — so "build my own" means reimplementing something you could have running this afternoon with a compose file. And what you would be reimplementing is not a chat window. It is mobile push through APNs and FCM with a proxy you operate, message delivery that survives a phone in a tunnel, search across three years of channels with permissions applied, file storage full of things people should not have uploaded, and a retention policy for the place your company says everything out loud. You will demo it in a weekend. Then colleagues start depending on it, and you are the entire on-call rota for their working day.
What actually breaks
not "if". the specific failures.
- Mobile push. Self-hosted chat needs your own APNs certificate, an FCM key and a push proxy you operate, plus a decision about whether the notification body carries message text through two other companies’ infrastructure
- Delivery. A message that renders locally with a tick and never reached the database is the worst bug this class of application has, and it happens on trains, in lifts and on hotel wifi
- Search. Three years of messages with per-channel membership applied is a full-text index with an access filter, not a LIKE query, and retrofitting the filter is where the leak comes from
- Membership history: someone joins a private channel — do they see what was said before? Someone leaves the company — what happens to their direct messages, and who is allowed to read them?
- File uploads. Your colleagues will put contracts, passports and a database dump in there within the first month, and that store needs every protection the message table has
- Retention and export, which nobody asks for until legal wants everything one person wrote in Q2, and by then the answer has to already exist
An engineer runs the migration and posts in the channel that it is done. It appears on her screen with a tick, because the client optimistically renders before the server acknowledges, and the write actually failed against a full disk. Nobody else ever sees it. Two hours later a colleague, seeing no confirmation, runs the same migration again. Most of the following day goes on proving that the message existed on exactly one laptop and nowhere else, and the fix is the sentence you have been avoiding since the first commit: the client cannot be the authority on whether a message was sent.
Is that you?
the verdict is a default, not a law
- It is a toy for a group of friends and everybody involved knows it is a toy
- It is a one-way feed — deploy notifications, alerts, a status channel — rather than the place decisions get made
- You are adding a chat feature inside your own product and using a hosted realtime service for the transport
- Your team would use it for actual work, which makes every outage a company-wide stoppage with you as the only responder
- There is no mobile push story, because chat without notifications is email with extra steps
- You are the only person who could restore it from a backup
- Anyone might one day need to produce chat history for a dispute, an audit or a regulator
If you build it anyway
the checklist, then the prompt that enforces it
- Server-assigned message ids and an explicit acknowledged state in the client. Never render a message as delivered just because the client sent it.
- Persist before you broadcast. The database write is the event; the socket is only a notification that it happened.
- Decide push content before you build push. An id-only notification that makes the client fetch is more work and keeps message text off Apple’s and Google’s servers.
- Backups with a restore you have personally performed, plus an export in a documented format, before you invite the second person.
- Put permissions into the search index from the first commit. Bolting an access filter onto full-text search later is how private channels leak.
- Write a retention policy that covers messages, edits and uploaded files, and enforce it with a job rather than an intention.
- Before any of this: run Mattermost Team Edition or Zulip for a week and see whether you still want to build it.
I am building self-hosted team chat. Colleagues will depend on it, so delivery and durability come before every feature, and I want push-back on scope.
1. First, tell me plainly what it would cost me to run Mattermost Team
Edition or Zulip instead, and ask me why I am not doing that.
2. Message ids are assigned by the server. The client shows a message as
pending until the server acknowledges it, and never renders an optimistic
message as delivered. This is the failure I care about most: a message
that exists on one laptop and nowhere else.
3. Persist to the database before broadcasting to any socket. The write is
the event; the socket is a notification about the write.
4. Clients reconcile on reconnect by fetching everything after their last
acknowledged id, rather than trusting whatever the socket delivered while
they were away.
5. Build backup, a restore you make me actually perform, and a documented
export format before inviting a second user.
6. Apply channel membership inside the search index from the first commit.
Never filter permissions after retrieving results.
7. Decide push notification content explicitly. Default to id-only pushes
that make the client fetch the message, and tell me what each option
sends through Apple’s and Google’s servers.
8. Treat uploads as hostile and as sensitive at the same time: type and size
limits, no execution, storage with the same access rules as messages, and
deletion that actually deletes.
9. Implement retention and deletion for messages, edits and files as a
scheduled job, and state the window in the README.
10. Out of scope, and say so instead of half-building it: native mobile apps,
voice and video calls, SSO, threads across workspaces, and federation.
If I need any of those, tell me to stop and deploy something existing.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Almost immediately, and the honest comparison is not the paid tier. Mattermost Team Edition is free, open source and self-hosted, and it already ships the mobile apps, the push proxy and the search you would never finish; the free Entry edition caps history at 10,000 messages, and Professional is now quote-only. Paying starts to make sense when you want SSO, compliance export and someone else on the phone at the point your team cannot work without it.
$10/mo is cheaper than your weekend.
Export messages as JSONL keyed by channel, timestamp, author and thread root, with uploaded files beside them and a manifest that maps ids to paths — Mattermost’s own bulk import format is documented, so target it deliberately rather than hoping. Do the export once for real before anyone joins, because the thing you cannot reconstruct later is membership history: who was in which private channel when, which is exactly what any migration and any legal request will ask for.
The product itself, open source and self-hostable, which makes rebuilding it a decision rather than a necessity.
Open-source team chat with a genuinely better threading model and first-party mobile clients.
Self-hostable chat platform with its own push gateway, apps and admin tooling already built.
Questions
If Mattermost is open source, what is the paid tier actually for?
SSO and identity integration, compliance and eDiscovery export, high availability, and support — the things an organisation needs once chat stops being optional. Team Edition remains free and self-hosted for small teams, and the free Entry edition trades a message-history cap for the enterprise feature set.
Why is maintenance scored so high?
Because chat is never finished. Push certificates expire, mobile OS releases change background behaviour, search indexes need reindexing, file storage grows, and every one of those is invisible until the morning the whole team cannot talk to each other and you are the only person who knows where the logs are.
What about just using a hosted realtime service?
That is the sensible move if you are adding chat inside your own product: let somebody else own presence, fan-out and reconnection, and keep the message store as your own database. It does not save you from push notifications, search permissions or retention, but it removes the layer most likely to lose a message.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
A forum is a weekend. A paid community is a company that five hundred strangers have already given their card to.
A forum can be down for an hour. A chat room that is down for an hour is a Discord server by lunchtime.
A community isn't a feature you ship. It's a duty of care with a subscription attached and a report button.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice