05 · Business continuity messenger
MRM
When internet access disappeared, I built the tool my company needed to keep working.
MRM is a self-hosted company messenger I scoped, designed, built, and deployed during the shutdown. Around 40 people used it until normal access returned.
Why this product exists
Context
During the first days of war in Iran, normal internet access disappeared. The company could no longer depend on its cloud communication tools, and work slowed because coordination itself had become unavailable.
Product problem
The team did not need a new social platform. It needed a familiar, deployable communication path that could survive blocked registries, unreachable CDNs, intermittent connectivity, and limited operational support.
Who it serves
Employees and managers who needed direct and group coordination, file exchange, presence, and reliable message recovery during disruption.
What good looked like
Essential coordination continues even when external infrastructure does not.
What made it difficult
No reliable international network
Package registries, CDN assets, and cloud platforms could not be assumed available.
Urgent adoption
People needed to understand the product immediately, with no training program and little tolerance for novelty.
Intermittent connectivity
Short outages could not lose the conversation or leave outgoing messages in an unknown state.
Low operational overhead
The application and database needed to run on company-managed infrastructure without a cloud platform or globally installed process manager.
What I built first, and why
- 1Shipped
Reduce to the essential workflow
I scoped direct and group messaging, files, delivery state, presence, and admin approval before secondary customization.
- 2Live
Remove external runtime dependencies
Browser libraries are served locally; production dependencies are bundled; bootstrap can select reachable domestic Ubuntu mirrors.
- 3Live
Make interruption recoverable
IndexedDB caches conversations, outgoing messages queue locally, and reconnection synchronizes state.
- 4Shipped
Deploy and support real use
The system was installed on internal infrastructure and used by around 40 people until normal connectivity returned.
The calls I had to make
Use familiar messaging patterns
The interface follows established messenger behavior because pressured users needed confidence, not a new mental model.
A conventional self-hosted stack
Node, Express, Socket.IO, MongoDB, Nginx, and systemd kept the runtime understandable and recoverable on company infrastructure.
Recover from short network interruptions
Local caching and pending queues handle short interruptions; real-time communication still requires a reachable internal network path.
Private deployment boundary
MRM is positioned for company-managed infrastructure and explicitly requires security review before any public exposure.
How the system works
Browser/PWA
Framework-free client, locally served libraries, IndexedDB, service worker, and push.
Local network
HTTPS and WebSocket communication through Nginx without a public SaaS dependency.
Application
A Node and Express service exposes REST APIs; Socket.IO handles real-time events.
Persistence
A self-hosted MongoDB instance stores records; a local file store handles shared media and documents.
Operations
Systemd, bundled dependencies, mirror selection, and Nginx keep deployment recoverable.
What I personally owned
- Emergency problem framing, prioritization, interaction design, and implementation
- Real-time messaging, presence, delivery/read state, reactions, replies, files, and groups
- Offline queueing, local cache, reconnection sync, PWA, and push notifications
- Self-hosted deployment, network-aware bootstrap, admin approval, and adoption support
What you can inspect
Adopted during the disruption
About 40 people used MRM as an operational fallback through the shutdown until normal internet access returned.
Resilience is implemented
Bundled dependencies, local assets, mirror testing, systemd, offline queues, IndexedDB, and reconnect behavior are present in the working repository.
Documented technical limits
The project describes where it is resilient and where it still needs a reachable internal network and independent security review.
Where it stands today
MRM kept essential coordination available for an approximately 40-person company during shutdown conditions and remained in use until normal internet access returned.
What I learned
- 01
In a crisis, the best roadmap is the shortest route back to essential work.
- 02
Infrastructure constraints belong in product discovery, not only DevOps.
- 03
Adoption under pressure depends on familiarity and operational simplicity.