我们从其他创始人那里得到的最常见的问题是： “您如何与您的团队一起构建 150 个模块？”
诚实的回答是这个问题是错误的。我们不会构建 150 个出色的模块。我们正在建造 150 足够好 模块建立在少数真正构建良好的基础之上。这种区别就是整个架构。
采摘过程。
我们从一条规则开始： 仅当模块删除了我们的目标客户已经付费的 SaaS 订阅时，该模块才属于 Mewayz。
不是“可能付出代价”。不是“无法想象支付的费用”。目前，今天使用信用卡定期付款。该过滤器消除了我们理论上可以构建的 80% 的模块。
剩下的 20%（大约 150 个类别）是我们的典型 SMB 客户目前每月支付 $25–500 美元的类别。 CRM、HR、会计、支持、项目、营销——显而易见的。还有 POS、预订、合同、表格、调查、知识库、非政府组织管理、呼叫中心、人工智能文档生成器、培训中心。
Mewayz 中的每个模块都必须指向客户现有软件账单中的发票。
我们不建造什么。
值得注意的是 不 在Mewayz中，故意：
- 专业创意工具。 Figma、Adobe、Logic — 卓越的单一用途创意工具。捆绑在一起是对类别的侮辱。
- 开发商基础设施。 GitHub、哨兵、线性。相邻的宇宙，不同的买家，不同的工作流程。
- 沟通平台。 松弛，变焦。有一天可能会成为赌注，但网络效应太强大了，现在无法削弱。
- 企业IT。 身份、SSO、MDM。我们与 Okta 等集成；我们不会替换它们。
架构： 三层。
在没有 150 个团队的情况下交付 150 个模块的技巧是，大多数模块都不是独立的产品。他们是 共享原语上的配置。
我们构建了每个模块都使用的三个基础层：
第一层：数据主干
跨平台的统一数据模型——联系人、公司、项目、文档、事件、资金。每个模块都通过这个主干进行读写。 CRM 的“联系人”与会计的“客户”和帮助台的“票务员”是相同的记录。没有同步，没有重复。
第二层：工作流引擎
一个处理所有跨模块操作的工作流运行时。报价→发票→付款→佣金→工资。创建潜在客户 → 发送电子邮件 → 分配任务。工单开具 → SLA 计时器 → 升级。所有相同的引擎，按模块配置。
第 3 层：UI 套件
每个模块都是由相同的 40 个左右的组件构建的——列表视图、详细视图、看板、日历、表单构建器、报告构建器。新模块通过配置这些组件来发布，而不是通过从头开始设计屏幕。
路线图。
我们在 v1 中发布了大约 90 个模块，在 v2 中发布了接下来的 60 个模块。速度大约是每月 4-6 个新模块，加上对最常用的现有模块的持续深入工作。
模块按照由三个信号设置的顺序发货：
- 客户的要求，按交易规模加权。 来自 200 人的机构的一个请求的处理速度比来自单独用户的 10 个请求的速度要快。
- 什么取代了最昂贵的现有订阅。 让客户每月放弃 $300 工具的新模块胜过每月放弃 $30 工具的新模块。
- 什么解锁了垂直包装。 通过发布“PMS”，我们可以推出酒店套餐。发布“事务管理”让我们可以推出法律包。垂直包装的转换速度是水平模块的 3 倍。
模块品质， 老实说。
不同的模块有不同的完善程度。核心 30 个工具——CRM、HR、会计、服务台、项目、营销——与中小型企业层级的一流独立工具具有真正的竞争力。
接下来的 50 个产品质量“足以满足大多数客户的需求”。它们涵盖了独立产品 80% 的用例。剩下的 70 家处于“赌注”状态——他们做他们需要做的事情，他们对好的方面并不感到惊讶。
我们对此很坦率。宣传语并不是“每个模块都是最好的”。宣传语是“所有模块都以一种价格连接，并且不会出现 SaaS 蔓延的情况”。如果您需要一流的电子表格，请使用 Excel。如果您需要一流的套牌工具，请使用 Pitch。如果您的权衡是“一张账单，所有这些都很好”，那么您就是我们的客户。
我们通过艰难的方式学到了什么。
回顾过去，三件事：
- 模块数量是一个虚荣数字。 150 在营销中听起来令人印象深刻。客户真正关心的是他们使用的12个模块是否好。在内部我们痴迷于模块 深度 前20名，不算。
- 数据主干比模块花费的时间更长。 地基上 18 个月，实际表面积上 6 个月。如果我们从头开始重建，我们会在地基上花费更多。
- 迁移工具与模块一样重要。 让客户进入 Mewayz 最困难的部分不是构建目的地 - 而是将他们的数据从七个现任者中转移出来。我们在过去六个月中构建了 40 多个迁移工具。每一项都可将转化率提高大约 4%。
这一切都不光彩。这些都不能成为良好的发布推文。但这就是 v2 在其范围内发布的原因。接下来的 18 个月将重点关注客户实际使用的模块的深度，而不是新模块的数量。