Falkster's Messaging Gateway: A Prototype-First Ship Story

Most of what I write about prototype-first product development is argument. This one is receipts.

The short version

Falkster needed to talk to people where they already are, Signal, WhatsApp, and Telegram, without forcing them into a new inbox. The enterprise-default answer is three bespoke integrations, each with its own auth, rate limits, and failure modes, scoped in a PRD and handed to an integrations team. We went the other way: one Matrix homeserver as a single bridging layer, with bridges out to each platform, prototyped and tested against real accounts within days. Building it surfaced the real problem, which the brief could not have: bridge reliability varies wildly by platform, so the actual work was not integrate with three APIs, it was build a guard layer that behaves consistently even when the bridges do not. The spec you can write before you build is always thinner than the one you discover while building.

Falkster needed to talk to people where they already are, Signal, WhatsApp, Telegram, not force them into a new inbox. The obvious enterprise answer is to build and maintain separate integrations against each platform's API, each with its own auth model, rate limits, and failure modes. That is the kind of project that gets a PRD, a quarter of engineering time, and a dedicated integrations team in most companies.

We went a different way. Instead of three bespoke integrations, we routed through a Matrix homeserver as a single bridging layer, one protocol Falkster speaks natively, with bridges out to each platform. The brief was one page: users should be able to reach Falkster from the messaging app they already have open, without Falkster needing custom code per platform. The prototype was the homeserver bridge itself, stood up and tested against real accounts within days, not designed in the abstract and handed off. This is the instant-prototype loop applied to an infrastructure decision, not just a UI.

What the prototype told us that the brief could not have predicted: bridge reliability varies wildly by platform, WhatsApp's bridge behavior is not Telegram's bridge behavior, and the real engineering problem was not integrate with three APIs, it was build a guard layer that behaves consistently even when the underlying bridges do not. That is a materially different problem than the one we would have scoped in a traditional PRD, and we only found it by building the thing, not by writing more detailed requirements in advance. The consistency contract that guard layer enforces is exactly the kind of commitment I argue belongs in an eval, not a paragraph.

This is the argument for prototype-first in one sentence: the spec you can write before you build is always thinner than the one you discover while building. Matrix as the bridging layer was not in the first version of the plan. It showed up because we were building, hit the wall of maintaining three bespoke integrations, and changed direction in days instead of defending a roadmap slide in the next planning cycle. That is the same move Slack made at the org level: let evidence from the build redirect the plan, fast.