我们从其他创始人那里得到的最常见的问题不是关于定价或上市。这是一种安静的、有点可疑的： 像你这样规模的团队如何维持 150 个模块而不导致整个团队崩溃？ 诚实的答案是我们不维护 150 个模块。我们维护一个平台和其上一层非常薄的层。诀窍在于对给定作品属于哪一层的无情。
令人恐惧的数学。
如果你把 150 个模块想象成 150 个小应用程序——每个应用程序都有自己的数据模型、自己的权限、自己的计费、自己的通知——那么 22 个人显然是疯了。每个工程师有六个模块，每个模块都有自己的产品。没有团队能幸存下来。对于那种架构，这种担心是正确的。
但这不是架构。对于用户来说，CRM、发票工具和帮助台看起来像是三种不同的产品。在下面，它们是相同的一些原语：记录、关系、事件时间表、角色和权限、金钱、文档和通知总线。 差异主要在于词汇和布局，而不是机制。
我们不会打造 150 种出色的产品。我们正在构建少量精心构建的原语，配置有 150 种方式。
核心/模块分割。
所有困难都存在于核心中，并且一次性构建：身份、权限、关系数据层、支付、文件存储、搜索、审计日志、通知系统、导出引擎。这些是真正困难且真正共享的部分。此处修复的错误同时修复了所有 150 个模块。这里添加的功能（例如电子签名）可以立即供每个需要它的模块使用。
因此，模块是故意变薄的。它是一个数据模式、一组视图、一个或两个工作流程以及一个作业的词汇表。 “CRM”是一种配置，它表示：这些记录类型是潜在客户和交易，这是管道视图，这些是阶段，这是转换的含义。它完全依赖于核心。新模块主要是声明，而不是代码。
硬性规则：赢得你的独特性。
防止其腐烂的纪律是一条单一的规则，在审查中强制执行： 一个模块不允许特别，除非它真正赢得了它。 每当一个模块想要有自己的定制权限模型、自己的一次性通知格式、自己存储日期的私有方式时，默认答案是否定的。将其作为一般能力推入核心，否则就不做。
这在当下很烦人，但多年来却是决定性的。大多数“我们需要在这里定制一些东西”的请求实际上是“我们对一般情况没有进行足够的思考”。当您强制采用一般情况时，核心会变得更丰富，每个模块都会受益，并且即使模块数量增加，您必须保持的表面积也保持大致平坦。
我们放弃了什么。
这种方法有一个真正的成本，我们应该指出它。由专注于一项工作的团队构建的最佳点工具将在该工作上超越我们的同等模块。最深入的电子邮件平台具有我们没有的自动化功能。最深入的项目工具具有我们所没有的视图。我们不会假装不是这样。
我们用这种深度换取的是一致性——共享一个数据模型、一个登录、一个账单、一个导出和一个通知层的模块。对于 5-50 人的团队来说，这种一致性比任何单一类别中最后 20% 的深度更有价值。对于整个业务都属于这一类别的团队来说，事实并非如此。我们清楚地知道我们是为谁服务的，而架构正是我们能够为 22 名员工提供服务的原因。