The most common question we get from other founders isn't about pricing or go-to-market. It's a quiet, slightly suspicious one: how does a team your size maintain 150 modules without the whole thing collapsing? The honest answer is that we don't maintain 150 modules. We maintain one platform and a very thin layer on top of it. The trick is the ruthlessness about which layer a given piece of work belongs to.
The math that scares people.
If you imagine 150 modules as 150 little applications — each with its own data model, its own permissions, its own billing, its own notifications — then 22 people is obviously insane. That's six modules per engineer, each a product in its own right. No team survives that. The fear is correct, for that architecture.
But that's not the architecture. A CRM, an invoicing tool, and a help desk look like three different products to a user. Underneath, they're the same handful of primitives: records, relationships, a timeline of events, roles and permissions, money, documents, and a notification bus. The differences are mostly vocabulary and layout, not machinery.
We're not building 150 great products. We're building a small number of well-built primitives, configured 150 ways.
The core / module split.
Everything hard lives in the core, and it's built once: identity, permissions, the relational data layer, payments, file storage, search, the audit log, the notification system, the export engine. These are the parts that are genuinely difficult and genuinely shared. A bug fixed here is fixed for all 150 modules at once. A capability added here — say, e-signatures — becomes instantly available to every module that wants it.
A module, then, is deliberately thin. It's a data schema, a set of views, a workflow or two, and the vocabulary for one job. "CRM" is a configuration that says: these record types are leads and deals, this is the pipeline view, these are the stages, here's what a conversion means. It rides entirely on the core. A new module is mostly declaration, not code.
The hard rule: earn your uniqueness.
The discipline that keeps this from rotting is a single rule, enforced in review: a module is not allowed to be special unless it has truly earned it. Every time a module wants its own bespoke permission model, its own one-off notification format, its own private way of storing a date — the default answer is no. Push it into the core as a general capability, or don't do it.
This is annoying in the moment and decisive over years. Most "we need something custom here" requests are really "we haven't thought hard enough about the general case." When you force the general case, the core gets richer, every module benefits, and the surface area you have to maintain stays roughly flat even as the module count climbs.
What we gave up.
This approach has a real cost, and we should name it. A best-of-breed point tool, built by a team obsessed with one job, will out-feature our equivalent module on that one job. The deepest email platform has automation we don't. The deepest project tool has views we don't. We are not pretending otherwise.
What we trade that depth for is coherence — modules that share one data model, one login, one bill, one export, and one notification layer. For a team of 5–50, that coherence is worth more than the last 20% of depth in any single category. For a team whose entire business is that one category, it isn't. We know exactly who we're for, and the architecture is the reason we can serve them with 22 people.