二十年来，任何软件决策中最重要的幻灯片都有两栏： 建造 和 买。自己构建并拥有它，或者购买现成的并继续前进。企业架构的整个学科就是围绕这个岔路口搭建的脚手架。
那个叉子不见了。不是因为答案已经确定——而是因为问题在每个人的内心悄然发生了变化。对于 2026 年五到五十人的团队来说，构建几乎不再是理性的，“购买”不再意味着购买 一个 工具。这意味着将十二个堆叠在一起，将它们整合在一起，并永远保持它们之间的接缝。今天真正的决定不是建造还是购买。这是 购买一堆与购买捆绑包。
为什么 建造 为中小型企业而死。
当现成的选项很少并且您的需求确实不寻常时，构建软件就有意义了。对于现在的大多数企业来说，情况并非如此。您需要的类别——CRM、发票、预订、工资单——有四十种成熟的产品。您的需求与您规模的其他企业有 95% 的相同，而这 5% 的差异很少值得雇佣工程师。
所以小团队停止了建设。好的。但取代建筑物的东西并不是一次干净的购买。这是一种采购习惯：每当出现新需求时，就为其购买新工具。一封用于电子邮件。一个用于调度。一份用于合同。一个是第一个工具应该做但没有做的事情。
没有人决定用十二种产品来经营他们的业务。他们决定十二次来解决一个问题。
这就是陷阱。从来没有一个会议有人选择复杂性。它不断增加，一次一次合理的购买，直到堆栈本身成为公司中最大的非托管系统。
隐藏的第三列。
旧幻灯片有两栏，因为有两个选项。诚实的 2026 年幻灯片有三张，中间一张是每个人实际生活的一张：
- 构建 ——你自己写吧。很少有理由低于 200 人。
- 组装 — 购买十几个单点工具，并将它们与集成、Zapier 和偶尔的电子表格连接在一起。这是默认的，没有人选择它。
- 捆绑包 — 在一张账单上购买一个已包含预集成模块的平台。
“组装”列是昂贵的一列，其成本几乎完全不可见，因为它从不显示为行项目。它分布在集成胶水、上下文切换、协调、入门以及跨工具的缓慢数据税中。
捆绑与套件不同。
怀疑论者听到“捆绑”就会想到“套件”——定义了 2000 年代的臃肿、强制性、全有或全无的企业包。公平的本能。区别在于 2026 年捆绑包是 模块化：您打开所需的功能，模块共享一个数据层，您可以在一次导出中保留您的数据。该套件将您锁定。该捆绑包逐个模块地获得其保留，并让您行走。
模块化就是整个游戏。一套套房说“要么全部拿走，要么全不拿走”。一个好的捆绑包上写着“今天需要四个，准备好后拿第五个，如果你想要的话，这里就是门。”它是套件与单点工具的可选性的集成。
这对您的下一张幻灯片意味着什么。
下次当你公司里有人说“我们应该构建这个还是购买它”时，更有用的问题是： 我们是否要添加第十三个选项卡，或者合并我们拥有的十二个选项卡？ 构建对于几乎所有阅读本文的人来说都是一种干扰。实时的决定是您是否继续缴纳组装税，还是转向购买之前已集成的产品。
我们在这里显然不是中立的。但您不必相信我们所说的方向 - 只需数一下您团队浏览器中当前打开的选项卡，然后询问将它们放在哪一列即可。