一个客户在2021年打电话给我——声音里充满了恐慌。他在十四个月内花了140,000英镑建造一个定制发票平台。他的开发团队只交付了大约60%的规格。在第十一个月左右，他发现Invoice Ninja存在，是开源的，而且开箱即用地完成了他需要的90%的功能。而且是免费的。Invoice Ninja existed, was open-source, and did 90% of what he needed out of the box. For free.
关键要点：购买SaaS直到订阅税、数据所有权或工作流不匹配真正成为问题；当该工具是公司获胜方式的核心时才构建定制方案。Buy SaaS until the subscription tax, data ownership, or workflow mismatch genuinely bites; build custom when the tool is core to how the business wins.
那通电话让我有点不安。因为诚实的答案是：我也犯过相反的错误。Seahawk在2019年有个项目，我们花了八个月整合五个不同的SaaS工具——Airtable、Zapier、Typeform、HubSpot和一个定制的Webflow CMS——来管理一个客户工作流，回过头来看，一个15,000英镑的定制构建本来可以干净彻底地解决这个问题。到最后，我们在合并订阅上支付大约900英镑/月。算一下三年的数字。
两个极端都不一定是对的。任何向你兜售简洁规则的人——"总是构建"、"永远不构建"——都在兜售什么东西。所以这是我当一个创始人坐下来问我这个问题时实际使用的框架。
---
首先，承认你真正在决定什么
这不是技术决策。严格来说不是。这是穿着技术外衣的商业决策。
当你说"我应该构建还是购买？"时，你真正问的是：差异化在我的产品中的什么地方？如果你在考虑构建的东西是核心的竞争优势——客户选择你而不是浏览器中下一个标签的原因——那么构建可能是有意义的。如果这是基础设施、管理或商品功能，购买几乎肯定在真实成本上更便宜。reason customers will choose you over the next tab in their browser -- then building probably makes sense. If it's infrastructure, admin, or commodity functionality, buying is almost certainly cheaper in real terms.
我先问创始人一个问题：你的用户会看到这个东西吗？如果答案是肯定的，而且它以有意义的方式影响了他们的体验，那么可能值得自己构建。如果它是后台、运营或内部工具，自己构建的门槛应该非常高。Will your users ever see this thing?If the answer is yes and it shapes their experience in a meaningful way, it might be worth building. If it's back-office, operational, or internal, the bar for building should be very high.
---
构建的真实成本（这一点被严重低估了）
我直言不讳。自定义开发的成本比你想的要高，耗时比你被告知的要长，而且需要持续维护——没人会为此编制预算。
创始人实际上忘记计入的成本
- 维护和托管。这不是一次性的。除非你下架这个东西，否则你要永远负责。Not a one-off. You're on the hook forever unless you sunset the thing.
- 安全补丁。SaaS供应商为你处理这些。你自己构建，你就拥有它，包括凌晨2点的告警。A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- 新开发者的入职培训。如果你的首席工程师离职，下一个人需要学习你的代码库。那是数周的可计费时间。If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- 功能蔓延。利益相关者看到定制工具，就会假设它能做任何事情。范围不断扩大。成本随之增加。Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
我使用的一个粗略规则是：拿你最初的开发估算，乘以1.6得到现实的交付时间，再加上这个数字的20%作为年度维护费用。如果这些数字仍然能说明商业价值，那很好。如果不能，你就有了答案。
说实话，Standish Group的CHAOS报告数十年来一直显示软件项目的预算超支率触目惊心。大约45-50%的项目处于"存在问题"或彻底失败。这不是永远不构建的理由——而是要求你睁大眼睛看清楚。Standish Group's CHAOS Report has been showing for decades that software projects overrun their budgets at an alarming rate. The number sits around 45-50% of projects being "challenged" or outright failing. That's not a reason to never build -- it's a reason to go in clear-eyed.
---
SaaS的真实成本（同样被低估，只是方式不同）
SaaS看起来很便宜，直到它变得不便宜。
年初看起来合理的49英镑/月计划到第三年有个有趣的习惯变成490英镑/月——一旦你升级到更高的等级，你添加了席位，供应商进行了"定价重组"（读作：涨价）。我见过Salesforce、Intercom和Mixpanel的客户发生这种情况。这不是恶意的。这就是SaaS经济的工作方式。
创始人陷入的三个SaaS陷阱
- 供应商锁定。你的数据采用他们的格式、他们的架构、他们的导出流程。离开会很痛苦，有时在没有大量数据工程工作的情况下实际上是不可能的。Your data is in their format, their schema, their export flow. Leaving is painful and sometimes effectively impossible without significant data engineering work.
- 拼凑堆栈的复杂性。五个工具通过 Zapier 勉强集成不是一个系统。这是一个隐患。一个 API 被弃用，整个系统就开始崩溃。Five tools that sort-of integrate via Zapier is not a system. It's a liability. One API deprecation and things start falling apart.
- 订阅蔓延。没有人每年审计一次他们的工具栈。他们应该这样做。我去年为一家 12 人的代理机构进行了审计，发现每月有 3,200 英镑的 SaaS 他们要么已经停止使用，要么只在使用一项功能。Nobody audits their tool stack annually. They should. I ran an audit for a 12-person agency last year and found £3,200/month in SaaS they'd either stopped using or were using for one feature each.
话虽如此——对于商品功能，SaaS几乎总是正确的选择。电子邮件传递？Postmark或SendGrid。付款？Stripe，显然。身份验证？Auth0或Clerk。2024年没人应该在构建自己的支付处理器。Postmark or SendGrid. Payments? Stripe, obviously. Auth? Auth0 or Clerk. Nobody should be building their own payment processor in 2024.
---
一个真正有效的框架
好的。这是我的思考方式。四个问题，按顺序来。
问题1：这是竞争差异化因素吗？
如果是——如果这是让你的产品真正与众不同的东西——构建值得认真考虑。如果不是，到此为止。购买。
问题2：是否存在足够好的SaaS替代方案？
足够好，不一定完美。创始人经常因为"市面上没有完全符合我们需求的东西"而自己构建。有时这是真的。通常意味着他们没有充分研究，或者他们把"我们需要好好配置这个"和"我们需要构建全新的东西"混为一谈。
在推荐任何定制开发之前，我至少要花两小时研究SaaS市场。Product Hunt和G2在这里真的很有用——不是作为绝对真理，而是作为一个起始的参考清单。Product Hunt and G2 are genuinely useful here -- not as gospel but as a starting inventory.
问题3：你的现实上线时间是多少？
SaaS工具可以今天就上线。定制开发最少需要几周，通常要几个月。如果速度很重要——在早期公司中几乎总是如此——购买现成产品能给你时间去了解你真正需要什么，然后再承诺去构建它。
早在2022年，Seahawk与一家物流创业公司合作，他们想要一个定制的路线优化仪表板。我们说服他们先使用白标API层（他们以Route4Me作为起点）。六个月后，他们完全清楚了客户真正关心的三个功能。他们最终委托的定制开发范围减半了——但质量翻倍了——因为他们在实际生产中学到了东西，而不是在需求文档中。Route4Me as a starting point). Six months later, they knew exactly which three features their customers actually cared about. The custom build they eventually commissioned was half the scope -- and twice as good -- because they'd learned in production rather than in a spec document.
问题4：当这个出故障时会发生什么？
因为它会坏。问题是谁来修复以及修复有多快。使用SaaS，你提交支持工单，在Twitter上抱怨。使用定制软件，你打电话给你的开发团队。如果你没有留用的开发团队，你就麻烦了。这不是假设——我见过创始人被坏掉的定制软件困住数周，因为他们的自由职业开发者去度假了。
---
何时构建是明智之举
有些情况下自定义显然是正确的选择。让我直言不讳地说出来。
- 你的核心 IP 是软件本身。如果你在销售 SaaS 产品，你不能外包你正在销售的东西。If you're selling a SaaS product, you can't outsource the thing you're selling.
- 监管要求意味着现成的工具不够。某些金融科技、医疗保健和法律应用有大多数 SaaS 工具无法满足的合规约束。Certain fintech, healthcare, and legal applications have compliance constraints that most SaaS tools aren't built to satisfy.
- 你已经用 SaaS 工具进行了验证，你准确地知道你需要什么。在委托自定义构建之前，这是可能的最好位置。This is the best possible position to be in before commissioning a custom build.
- 大规模的 SaaS 定价确实比自有成本更高。在你预计的第 3 年使用量处进行计算。有时自定义构建在纯经济上赢了。Do the maths at your projected Year 3 usage. Sometimes custom wins on pure economics.
---
何时购买显然是正确的选择
同样地，有些情况下购买是显而易见的：
- 你还没有营收或没有达到产品与市场匹配。就这样。
- 这些功能是通用基础设施——邮件、支付、身份认证、存储、分析。
- 你需要它在本季度上线，而不是明年。
- 你的团队内部没有工程能力，也承担不起正规招聘。
我还要补充：如果你作为创始人进行构建是为了避免做出更难的业务决策，那值得审视。定制构建可能是一种非常昂贵的拖延形式。to avoid making a harder business decision, that's worth examining. Custom builds can be a very expensive form of procrastination.
---
混合策略（通常是最聪明的做法）
这是没人充分讨论的事：构建和购买并不互斥。
我看到反复有效的最实用方法是这样的——积极购买通用部分，然后在顶部构建一个薄的差异化逻辑层。你的CRM是HubSpot。你的支持台是Intercom。但那个连接它们并自动化你特定流程的定制工作流引擎？那是两周的定制开发，而不是六个月。
在Seahawk，我们用WordPress——一个已有的平台——构建了数百个网站，配合做真正新颖事情的定制插件。平台处理了80%。我们构建那20%的关键部分。这是老套的建议。也是最常奏效的建议。WordPress -- a bought platform -- with custom plugins that do genuinely novel things. The platform handles the 80%. We build the 20% that matters. It's boring advice. It's also the advice that's worked most often.
---
常见问题
我如何知道我的用例是否真正独特到足以证明自定义构建的合理性？
老实答案：大多数不必要。先花一个认真的下午——我是说四五个小时，不是二十分钟——映射你这一类别的所有SaaS产品。如果你已经这样做了，但什么都没有覆盖你的核心需求，问问自己那个需求现在是否真的必要，还是一个你升格成阻碍的锦上添花。如果它真的必要且真的无人满足，那是一个值得认真对待的信号。necessary right now or whether it's a nice-to-have you've elevated into a blocker. If it's truly necessary and truly unserved, that's a signal worth taking seriously.
负责任地拥有定制软件最少需要什么样的团队？
最少需要：一个深刻理解代码库的开发者，加上要么一个第二开发者、要么一个留用的代理机构在他们无法工作时覆盖。仅用一个自由职业者且没有备份地拥有定制软件是一个脆弱的位置。我见过当那一个人无法工作时——度假、生病、更好的工作机会——造成真正的运营损害。
我应该自己构建还是雇佣一个机构来构建定制软件?
这几乎完全取决于软件是否是你的核心业务。如果你是一家软件公司,即使你用机构来快速启动,你最终几乎肯定会想要内部团队。如果软件是支持你业务的工具而不是业务本身,一个有适当SLA的机构关系通常比全职招聘工程师更具成本效益。
开源是在构建和购买之间的中间路径吗?
是的，而且这种方法被利用不足。像Metabase这样的分析工具、Directus这样的无头CMS，或ERPNext这样的运营工具，给你定制软件的灵活性，同时显著降低初始构建成本。代价是：你仍然拥有基础设施，你仍然需要有人在技术上管理它。这不是免费的——只是启动成本更低。Metabase for analytics, Directus for headless CMS, or ERPNext for operations give you the flexibility of custom software with significantly lower initial build cost. The catch: you're still owning infrastructure and you still need someone technical to manage it. It's not free -- it's just cheaper to start.
---
最后的想法
构建与购买的问题没有一个答案。它有你的答案，具体到你的阶段、你的团队、你的竞争位置，以及你到目前为止实际验证过的内容。your answer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
我要反驳的是围绕自主开发的浪漫化想法。定制软件并不一定比配置得当的 SaaS 堆栈更严肃、更可扩展或更令人印象深刻。我在开始时提到的那位发票应用创始人？他最终确实构建了真正的定制软件——但这是在十八个月使用 Invoice Ninja 之后，那段时间让他明确了客户真正需要什么。等待让这次构建变得更好。
从无聊的选项开始。通过使用赢得构建新东西的权利。