One tech base, forty buildable workspaces

Our monorepo holds 40 buildable product workspaces across six stacks — proof that a harness-and-kit approach can stand up a competitive product in weeks.

A broad wooden table filling the frame with a varied group of everyday objects standing on it — a bowl, a folded cloth, a box, a tray.

'We can build anything fast' is one of the cheapest claims in software. So we tried to make ours falsifiable. Our monorepo contains 40 buildable product workspaces spanning six stacks — web, native mobile, desktop, realtime backends, realtime voice, and a developer SDK — all struck from the same foundation and sharing one agent harness and one guard stack. The claim is not a slogan; it is a directory you could count.

The production suite is the anchor

The clearest proof is the software we actually run. Our flagship voice product alone spans seven surfaces — a consumer web app, a native mobile app, a desktop console, the operations layer around them, and the backend and voice service underneath — all built from the same conventions for authentication, data, deployment, and observability. Beside it sit the operator console, the corporate site, the platform backend, and the voice engine itself. These are not prototypes. They are the things a small team keeps in production motion at the same time, which is only possible because they are not really separate codebases so much as one tech base wearing different faces.

The adaptability lab

Then there is the part that exists purely to test range. We have built 24 full, working parity rebuilds of category-leading products — across communication and social, media and streaming, productivity, commerce, health and wellness, and finance — plus a handful of original products of our own. We are careful about what this is and is not. These rebuilds are internal engineering studies: capability proof, not shipped products. They are not deployed, not sold, and we do not count them as traction. What they demonstrate is that the same team, harness, and conventions can reproduce production-grade patterns in wildly different domains, quickly, without a new stack each time.

That distinction matters to us. It would be easy to dress the studies up as a portfolio, and easy to overclaim. The honest version is more useful: they are a stress test for the factory, and the fact that a small team could run that many of them is the real signal.

The reason the studies are cheap enough to run at all is that the six stacks share more than a repository. They share the same patterns for authentication, data, deployment, and observability, and a developer SDK that packages the common surface once instead of per product. So a rebuild in commerce and a rebuild in health are not two from-scratch efforts; they are the same foundation pointed at two different problems, which is exactly why range stops being expensive.

Kits turn range into speed

The lab was not busywork — it distilled into starter kits that make the next product fast. There is an app template for standing up a full-stack web app on day one, an aperture kit for realtime voice and media pipelines, and a backend kit that bakes in the conventions for data, auth, and APIs. Together they mean a new product starts at mile ten instead of mile zero: the undifferentiated first month of engineering is already done, and a new vertical can go from nothing to a running app in days.

This is the same playbook that produced our caregiving vertical and a full-stack banking platform built on an open-source core. Neither started from a blank repository; both started from kits that had already absorbed the boring, load-bearing decisions, so the team could spend its attention on what actually made each product different.

That banking build is worth being precise about, because it is easy to overclaim. It is a working full-stack platform assembled on top of an open-source core-banking engine — a real double-entry ledger, transfers, standards-based single sign-on, sanctions screening, and asynchronous settlement — which demonstrates the team can integrate and extend serious financial infrastructure. It is a capability study, not a bank we operate, and we describe it as exactly that. The point is not the domain; it is that a foundation built for voice care could be pointed at core banking and reach a working system without a new toolchain.

One base, proven forty times

Put together, the picture is simple. One tech base, one agent harness, one deploy guard stack — and forty places it has already been stood up. The point of consolidating everything onto a single foundation is not tidiness; it is leverage. Every improvement to the harness or the kits compounds across every product at once, and every product built on them is another proof that the foundation holds.

It is worth being clear about what the number does and does not mean. Forty workspaces is not forty businesses; it is forty things a small team can build, run, and reason about without a new toolchain for each. That is the claim we set out to make falsifiable, and the monorepo is the evidence: six stacks, one set of conventions, and a growing record that the approach scales with the team rather than against it.

This note describes the implementation as it stood when it was written. Figures are counted from the repository; they are not published benchmarks or a performance guarantee.