一个客户在2021年给我打电话，声音里充满了恐慌。他花了14万英镑，用了14个月构建一个自定义发票平台。他的开发团队完成了大约60%的规范。到了第11个月左右，他发现Invoice Ninja存在、是开源的，而且开箱即用就能做到他需要的90%功能。而且是免费的。
关键要点：购买SaaS直到订阅税、数据所有权或工作流不匹配真正成为问题；当该工具是公司获胜方式的核心时才构建定制方案。
那通电话一直在我心里。因为诚实的答案是：我也犯过相反的错误。Seahawk在2019年有个项目，我们花了8个月把5个不同的SaaS工具——Airtable、Zapier、Typeform、HubSpot和一个自定义的Webflow CMS——拼凑到一起来管理一个客户工作流，而事后看来，一个1.5万英镑的自定义构建本来可以干净彻底地解决这个问题。到最后我们在组合订阅上每月支付大约900英镑。算算三年的账。
两个极端都不一定是对的。任何告诉你一个干净规则"总是构建"或"永不构建"的人，都在兜售什么东西。所以这是我当一个创始人坐下来问我这个问题时实际使用的框架。
---
首先，承认你真正在决定什么
这不是技术决策。严格来说不是。这是穿着技术外衣的商业决策。
当你说"我应该构建还是购买？"时，你实际上在问的是：差异化的所在是什么？如果你考虑构建的东西对你的竞争优势至关重要，是客户选择你而不是选择浏览器中下一个标签页的原因，那么构建可能是有意义的。如果它是基础设施、管理或商品功能，购买几乎肯定在实际成本上更便宜。
我先问创始人一个问题：你的用户会看到这个东西吗？如果答案是肯定的，而且它以有意义的方式影响了他们的体验，那么可能值得自己构建。如果它是后台、运营或内部工具，自己构建的门槛应该非常高。
---
构建的真实成本（这一点被严重低估了）
我直言不讳。自定义开发的成本比你想的要高，耗时比你被告知的要长，而且需要持续维护——没人会为此编制预算。
创始人实际上忘记计入的成本
- 维护和托管。这不是一次性的。除非你下架这个东西，否则你要永远负责。
- 安全补丁。SaaS供应商为你处理这些。你自己构建，你就拥有它，包括凌晨2点的告警。
- 新开发者的入职培训。如果你的首席工程师离职，下一个人需要学习你的代码库。那是数周的可计费时间。
- 功能蔓延。利益相关者看到定制工具，就会假设它能做任何事情。范围不断扩大。成本随之增加。
我使用的一个粗略规则是：拿你最初的开发估算，乘以1.6得到现实的交付时间，再加上这个数字的20%作为年度维护费用。如果这些数字仍然能说明商业价值，那很好。如果不能，你就有了答案。
说实话，Standish Group的混沌报告几十年来一直显示软件项目的成本超支比例惊人。大约45-50%的项目被列为"挑战性"或彻底失败。这不是永不构建的理由，但这是清醒地看待问题的理由。
---
SaaS的真实成本（同样被低估，只是方式不同）
SaaS看起来很便宜，直到它变得不便宜。
年初看起来合理的49英镑/月套餐，到了第三年有种奇怪的习惯会变成490英镑/月，一旦你升到了更高层级、增加了座位数，供应商又进行了一次"定价重构"（读作：涨价）。我看着这种情况在Salesforce、Intercom和Mixpanel上的客户身上发生过。这不是恶意的。这只是SaaS经济学的运作方式。
创始人陷入的三个SaaS陷阱
- 供应商锁定。你的数据采用他们的格式、他们的架构、他们的导出流程。离开会很痛苦，有时在没有大量数据工程工作的情况下实际上是不可能的。
- 拼凑堆栈的复杂性。五个工具通过 Zapier 勉强集成不是一个系统。这是一个隐患。一个 API 被弃用，整个系统就开始崩溃。
- 订阅蔓延。没有人每年审计一次他们的工具栈。他们应该这样做。我去年为一家 12 人的代理机构进行了审计，发现每月有 3,200 英镑的 SaaS 他们要么已经停止使用，要么只在使用一项功能。
话虽如此，对于商品功能，SaaS几乎总是正确的选择。电子邮件投递？Postmark或SendGrid。支付？显然是Stripe。身份验证？Auth0或Clerk。在2024年没人应该自己构建支付处理器。
---
一个真正有效的框架
好的。这是我的思考方式。四个问题，按顺序来。
问题1：这是竞争差异化因素吗？
如果是的，如果这就是让你的产品真正不同的东西，构建值得认真考虑。如果不是，到此为止。购买。
问题2：是否存在足够好的SaaS替代方案？
足够好，不一定完美。创始人经常因为"市面上没有完全符合我们需求的东西"而自己构建。有时这是真的。通常意味着他们没有充分研究，或者他们把"我们需要好好配置这个"和"我们需要构建全新的东西"混为一谈。
在我推荐自定义构建前，我至少要花两小时研究SaaS市场。Product Hunt和G2在这里真的很有用，不是作为绝对真理，而是作为一个起始清单。
问题3：你的现实上线时间是多少？
SaaS 工具可以今天就上线。定制开发至少需要几周，通常是几个月。如果速度很重要——在早期公司中几乎总是如此——购买 SaaS 能给你时间去了解你真正需要什么，然后再承诺去构建它。
早在 2022 年，Seahawk 与一家物流初创公司合作，他们想要一个定制的路线优化仪表板。我们说服他们先使用白标 API 层（他们以 Route4Me 作为起点）。六个月后，他们清楚地知道了客户真正关心的三项功能。他们最终委托开发的定制系统范围只有一半，但质量提高了一倍，因为他们在生产环境中学习，而不是在需求文档中。
问题4：当这个出故障时会发生什么？
因为它会出问题。问题是谁来修复以及修复速度有多快。使用 SaaS，你提交支持工单然后在 Twitter 上抱怨。使用定制软件，你打电话给开发团队。如果你没有保留的开发团队，你就麻烦了。这不是假设，我见过创始人被破损的定制软件困住好几周，因为他们的自由职业开发者去度假了。
---
何时构建是明智之举
有些情况下自定义显然是正确的选择。让我直言不讳地说出来。
- 你的核心 IP 是软件本身。如果你在销售 SaaS 产品，你不能外包你正在销售的东西。
- 监管要求意味着现成的工具不够。某些金融科技、医疗保健和法律应用有大多数 SaaS 工具无法满足的合规约束。
- 你已经用 SaaS 工具进行了验证，你准确地知道你需要什么。在委托自定义构建之前，这是可能的最好位置。
- 大规模的 SaaS 定价确实比自有成本更高。在你预计的第 3 年使用量处进行计算。有时自定义构建在纯经济上赢了。
---
何时购买显然是正确的选择
同样地，有些情况下购买是显而易见的：
- 你还没有营收或没有达到产品与市场匹配。就这样。
- 这些功能都是商品化基础设施：邮件、支付、身份认证、存储、分析。
- 你需要它在本季度上线，而不是明年。
- 你的团队内部没有工程能力，也承担不起正规招聘。
我还要补充：如果你作为创始人进行构建是为了避免做出更难的业务决策，那值得审视。定制构建可能是一种非常昂贵的拖延形式。
---
混合策略（通常是最聪明的做法）
这是没人充分讨论的事：构建和购买并不互斥。
我看到反复有效的最实用方法是这样的：激进地购买商品化组件，然后在上面构建薄薄的差异化逻辑层。你的 CRM 是 HubSpot。你的支持台是 Intercom。但那个连接它们并自动化你特定流程的定制工作流引擎？那是两周的定制开发，而不是六个月。
在 Seahawk，我们已经在 WordPress 这个购买的平台上构建了数百个网站，配合做真正创新事情的定制插件。平台处理 80%。我们构建占有 20% 的部分。这是很无聊的建议。但也是最常见的有效建议。
---
常见问题
我如何知道我的用例是否真正独特到足以证明自定义构建的合理性？
老实说：大多数都不是。先花一个认真的下午——我指的是四五个小时，不是二十分钟——列出你这个类别中的每个 SaaS 产品。如果你已经这样做了，仍然没有东西覆盖你的核心需求，那就问问自己这个需求现在是否真的必要，或者它是你升级成阻挡者的一个锦上添花的东西。如果它真的必要且真的无人服务，那是一个值得认真对待的信号。
负责任地拥有定制软件最少需要什么样的团队？
至少：一个深入理解代码库的开发者，以及一个第二开发者或保留的机构来在他们不在时提供支持。仅用一个自由职业者且没有备份的情况下拥有定制软件是一个脆弱的位置。我见过这种情况在那个人变得不可用时（度假、生病、更好的工作机会）造成真正的运营损害。
我应该自己构建还是雇佣一个机构来构建定制软件?
这几乎完全取决于软件是否是你的核心业务。如果你是一家软件公司,即使你用机构来快速启动,你最终几乎肯定会想要内部团队。如果软件是支持你业务的工具而不是业务本身,一个有适当SLA的机构关系通常比全职招聘工程师更具成本效益。
开源是在构建和购买之间的中间路径吗?
是的，而且使用不足。像 Metabase 这样的分析工具、Directus 这样的无头 CMS，或 ERPNext 这样的运营系统给你定制软件的灵活性，但初始构建成本明显更低。问题是：你仍然需要拥有基础设施，仍然需要有人在技术上管理它。它不是免费的，只是启动成本更便宜。
---
最后的想法
构建与购买的问题没有一个答案。它有你的答案，具体到你的阶段、你的团队、你的竞争位置，以及你到目前为止实际验证过的内容。
我要反驳的是围绕构建的浪漫化。定制软件本身并不比配置良好的 SaaS 堆栈更严肃、更可扩展或更令人印象深刻。我一开始提到的那位发票创始人？他最终确实构建了一些真正定制的东西，但那是在使用 Invoice Ninja 十八个月之后，他才准确学到了客户真正需要什么。等待让这个构建更好。
从无聊的选项开始。通过使用赢得构建新东西的权利。
相关阅读：使用 Next.js 和 Supabase 构建实时拍卖网站、定制网络开发和 Next.js。