Commons
Scheduled Oct 9, 2026Internal messaging you host. External federation you will miss.
Replaces
- Slack · Slack Technologies, LLC (Salesforce) — $15 per seat per month (Business+ (billed annually)), about $72,000/yr at 400 seats
- Microsoft Teams · Microsoft Corporation — $4 per seat per month (Microsoft Teams Essentials (annual subscription)), about $19,200/yr at 400 seats
Rented, per year
$72,000
Slack list price at 400 seats.
Owned, per year
$10,800
AWS infrastructure only. Azure is $11,640.
Build
16 weeks
3 engineers. To parity on the ten core features, including the gateway, native mobile shells with push, search, retention and legal hold, the bot API, and migration of Slack history, channels, threads, files and reactions. This is the largest build in the library and the only one where we routinely advise clients not to proceed. Voice, video and external federation are explicitly out of scope and are not costed here.
Difficulty
5/5
Among the hardest in Techtons. Read the parity table closely.
Reference organisation: 400 employees, ~900 concurrent device connections at peak, 250 channels, ~2M messages per year, 400 GB of files, 5-year retention with legal hold, single region, prod + non-prod. 3-year Compute Savings Plan on Fargate / 3-year reservation on Container Apps. Gateway sized for 2.5x peak concurrency. Aurora minimum 0.5 ACU; message partitions older than 12 months on cheaper storage but still online. Azure figure includes the workload-profiles baseline and Web PubSub units for the stated connection count. Excludes any meeting or telephony platform you retain, and excludes the Slack or Teams licences you keep for external collaboration. These figures are infrastructure only and exclude the build. For comparison, 400 users on Slack Business+ at the listed $15 per user per month billed annually is $72,000 a year.
What it is
Commons is internal messaging: channels, threads, direct messages, presence, search, files, mentions, custom emoji and a bot API, running on your own infrastructure with every message in a Postgres database you control. This is the hardest replacement in the library and we rate it a 5. Read the parity table before anything else. Commons handles internal chat well. It does not federate with other organisations, it does not carry voice or video, and it does not have Slack's app directory. If your Slack workspace is load-bearing for external collaboration, or if Teams is already bundled into an M365 agreement you are paying for regardless, the honest answer is that replacing it is not the highest-value thing we could build for you.
Why this one stops making sense
- Slack Business+ is $15 per user per month billed annually. At 400 users that is $72,000 a year for internal chat, and Slack's pricing rises with headcount whether or not usage does.
- Your message history is the company's most complete informal record — decisions, incidents, negotiations, complaints — and it lives in a third-party system with retention controls gated behind the top pricing tier.
- Data residency and e-discovery obligations attach to chat exactly as they do to email, and satisfying them on a hosted platform usually means buying a further tier or a further product.
- Bots and integrations accumulate into real workflow — deploy notifications, incident channels, approval prompts — and each one holds a token to a system outside your perimeter.
- Guest accounts and shared channels quietly extend your messaging surface to partner organisations under governance nobody reviews. Owning the platform makes that boundary explicit.
What ships
- Public and private channels, threads, direct messages and group DMs
- Real-time delivery over WebSocket with typing indicators, presence and read cursors per device
- Message editing, deletion, pinning, saving and reactions with custom emoji
- Full-text search across messages, threads and file contents, scoped by channel membership
- File sharing with inline preview, virus scanning on upload and per-channel retention policy
- Retention and legal hold per channel, with an export that satisfies e-discovery formats
- Bot and incoming-webhook API with a slash-command framework and interactive message components
- Channel-level access driven by IdP groups, with automatic membership on group change
- Huddle-free focus tools: scheduled sends, reminders, do-not-disturb honouring working hours from the HRIS
- Shared documents inside a channel, collaboratively edited, for running notes and incident timelines
Data model
Stack
- frontend
- Next.js 15 App Router + Tailwind + TanStack Query; native shells around the PWA for push
- backend
- A Go gateway service for WebSocket connections and fan-out; NestJS on Node 22 for the REST API and bot surface
- database
- PostgreSQL 16, messages in a partitioned append-only table by month, Row Level Security per workspace
- cache
- Redis 7 for presence, connection registry, unread counters and the recent-message tail per channel
- queue
- BullMQ for push notification dispatch, search indexing, retention enforcement and exports
- auth
- OIDC against the customer IdP; SCIM 2.0 for provisioning and deprovisioning; per-device session tokens
- search
- PostgreSQL tsvector with a per-channel partial index, plus pg_trgm for name and emoji lookup
- ai
- Optional: channel catch-up summaries and thread recaps through a pluggable LLM gateway, run on request and never on the full corpus by default
Parity, honestly
What we match, and what we do not.
The rows marked No are the important ones. If one of them is the reason you bought Slack, keep buying it — and we will tell you that on the first call rather than the fifth month.
| Capability | Slack | Ours | Note |
|---|---|---|---|
| Channels, threads and direct messages | Yes | Yes | — |
| Real-time delivery, presence and typing indicators | Yes | Yes | — |
| Search across message history | Yes | Yes | Unlimited history, which Slack's Pro tier limits and Business+ prices. |
| Retention policy and legal hold | Partial | Yes | Slack gates the useful retention controls behind higher tiers. Commons treats them as table stakes. |
| Bot API, slash commands and webhooks | Yes | Yes | Deliberately Slack-shaped so existing internal bots port with modest changes. |
| Unlimited free seats | No | Yes | — |
| Federation with other organisations (Slack Connect / Teams external access) | Yes | No | This is the gap that decides the project. Slack Connect lets a channel span two companies' workspaces with identity, retention and compliance handled on both sides. Teams does the equivalent through Entra B2B. There is no open protocol both ends already speak — Matrix federates, but your customers and suppliers are not on Matrix. Commons supports time-boxed guest accounts on your own instance, which means the external party creates yet another login rather than using their own tool. If a meaningful share of your daily conversation is with people outside the company, keep Slack for that and run Commons internally, or do not do this at all. |
| Voice, video and screen sharing | Yes | No | The second decisive gap. Huddles and Teams meetings are real-time media, which means an SFU, TURN servers, echo cancellation, network adaptation, recording and transcription — a product of comparable size to Commons itself, with an operational profile nothing else in this catalogue has. Commons deep-links into whatever meeting tool you already run. It does not carry media. |
| App directory with thousands of third-party integrations | Yes | No | Slack's directory is a genuine ecosystem: Jira, PagerDuty, Zoom, Salesforce, hundreds more, installed by a non-technical admin in two clicks. Commons has an API and the four or five integrations we build. Every other one is an engineering ticket. |
| Telephony, PSTN calling and meeting rooms | Yes | No | Specific to Teams. Teams Phone is a licensed calling platform with carrier interconnect. Nothing in Commons addresses it. |
| Native desktop and mobile apps with reliable push | Yes | Partial | Commons ships a PWA plus native mobile shells for push. Push itself still goes through APNs and Firebase Cloud Messaging — Apple and Google operate those rails and no self-hosted messenger escapes them. Notification reliability is the single most-cited complaint about self-hosted chat and it takes real engineering to get right. |
| Compliance and DLP vendor ecosystem | Yes | Partial | Slack and Teams have certified integrations with the major e-discovery and DLP vendors. Commons exports in standard formats and exposes a compliance event stream; wiring it to a specific vendor is a connector we build. |
| Message search quality at scale | Yes | Partial | Postgres full-text search over five years of messages is good, and it is not as good as Slack's. If search quality is the reason people love the tool, weigh that honestly. |
| Migration without losing the network | Yes | No | We import history, channels, files and threads. What does not migrate is the habit and the external reach. Every failed internal-chat migration we have seen failed on adoption, not on features. |
Reference architecture
Built twice, on purpose.
Every application in Techtons ships with a production architecture for AWS and one for Azure, using the same diagram grammar so you can read them side by side. Your cloud, your account, your bill.
Amazon Web Services
- Compute
- ECS Fargate: a Go gateway service holding WebSockets, an API service, and workers
- Data
- Aurora Serverless v2 PostgreSQL with a read replica for search; ElastiCache Redis
- Storage and edge
- S3 for file uploads and exports, GuardDuty Malware Protection on the upload bucket, CloudFront for delivery
- Identity
- Cognito federated to the customer IdP; device tokens signed with a KMS asymmetric key
- Observability
- OpenTelemetry to CloudWatch; connection count, reconnect rate and push latency as first-class metrics
- Infrastructure as code
- Terraform, with the gateway on its own target group and a long deregistration delay
Services
The decision worth arguing about
Two decisions matter here and neither is the one people expect. The first is connection cost, and the honest finding is that the reflex answer — never use API Gateway WebSockets — is wrong on the arithmetic. Messaging is the opposite load shape to a whiteboard: nine hundred sockets sitting idle all day and a modest message rate. API Gateway charges $0.25 per million connection-minutes, so nine hundred connections held continuously for a month is under forty million connection-minutes, around ten dollars, with messages costing a similar order. The reason we still run our own Go gateway on Fargate is not price, it is API Gateway's two-hour maximum connection duration and ten-minute idle timeout. A hard two-hour cap means every client reconnects at least twelve times a day; nine hundred clients gives you eleven thousand daily reconnects, each one a state resynchronisation that reads the user's channel cursors and replays what they missed. That is a permanent, self-inflicted load spike pattern and a permanent source of the exact bug users hate most in chat — the message that arrives twice or not at all across a reconnect. A Fargate task holds a socket for as long as the network allows and we control the drain. The second decision is fan-out, and here we deliberately do not use a CRDT. It is tempting, because Canvas in this same library is CRDT-based and the tooling is right there. It would be wrong: chat messages are immutable once sent and their ordering is assigned by the server, so a CRDT would buy no conflict resolution we need while accumulating unbounded per-channel state that every client would have to download. Message history is an append-only partitioned table, and the only CRDT in Commons is the shared-document feature inside a channel, where concurrent editing genuinely happens. Fan-out is then a hybrid: messages are fanned out on read — one row per message, with a per-user-per-channel read cursor — because fanning out on write into a four-hundred-member channel would multiply every message by four hundred rows for no benefit. What we do fan out on write is the small stuff: unread counters and mention flags, maintained incrementally in Redis, because computing them on connect for a user in sixty channels is sixty queries at exactly the moment the user is waiting for the app to load.
Microsoft Azure
- Compute
- Azure Container Apps for API and workers; the gateway on a workload-profiles environment
- Data
- PostgreSQL Flexible Server with a read replica; Azure Cache for Redis
- Storage and edge
- Blob Storage for uploads and exports with Defender for Storage scanning; Front Door for delivery
- Identity
- Microsoft Entra ID with SCIM provisioning; device tokens signed with a Key Vault key
- Observability
- Azure Monitor and Application Insights, with a custom active-connection metric driving scale
- Infrastructure as code
- Bicep, including the KEDA scaler and the drain hook for the gateway
Services
The decision worth arguing about
On Azure the connection decision genuinely flips, and it is worth contrasting with Canvas in this same library, where it went the other way. Azure Web PubSub prices in units that bundle a concurrent-connection allowance with a daily message allowance. A whiteboard burns message quota while barely touching connection capacity, which makes Web PubSub a bad fit there. Chat is the mirror image: high connection count, low message rate, exactly the axis the unit model is built around. So on Azure we do use Web PubSub for the socket layer and skip running our own gateway fleet, which removes the whole class of problems around scale-in terminating live connections. The trade-off is where the fan-out then has to live. Web PubSub's natural model is groups — you would put each channel in a group and let the service deliver — but a user in sixty channels across two devices means a hundred and twenty group memberships per person, and at four hundred people that is roughly forty-eight thousand memberships churning on every join, leave, login and logout, against a management API with its own rate limits. Group membership becomes a synchronisation problem you now own in two places. So Commons subscribes each connection to exactly one group, keyed by user, and does channel-to-user routing itself in the API service before publishing — trading the service's built-in fan-out for our own, which we were maintaining anyway for unread counters and push. The result is that Web PubSub is used as a durable, managed socket transport and nothing more, which is the part of it that is genuinely good. Mobile push goes through Notification Hubs rather than SNS, and the same caveat applies as on AWS: Apple and Google own the last hop and no amount of self-hosting changes that.
Sources
Every price on this page, with the page we read it from and the date we read it.
| Product | Plan | List price | Checked | Source |
|---|---|---|---|---|
| Slack | Business+ (billed annually) | $15 / seat/month | 2026-09-05 | slack.com/pricing Slack lists Pro at $7.25 and Business+ at $15.00 per user per month when paying annually ($8.75 and $18.00 monthly, with a promotional discount shown at the time of checking). Enterprise+ is quoted by sales. |
| Microsoft Teams | Microsoft Teams Essentials (annual subscription) | $4 / seat/month | 2026-09-05 | www.microsoft.com/en-us/microsoft-teams/comp Microsoft lists Teams Essentials at $4.00 per user per month paid yearly. Most organisations do not buy it standalone: Teams arrives inside Microsoft 365, where Business Basic is $7.00 and Business Standard with Copilot is $23.50 per user per month paid yearly. If Teams is already bundled in an M365 agreement you are paying for, replacing it saves nothing on that line. |
Should you still be paying for Slack?
Two weeks, fixed price. We audit what you actually use, map it against Commons, cost the replacement on your own AWS or Azure account, and give you a delivery plan. If the honest answer is to keep the licence, that is what the report will say.