一个客户在2021年打电话给我——声音里满是恐慌。他在14个月内花了14万英镑来开发一个定制发票平台。他的开发团队只完成了大约60%的功能规划。到了第11个月，他才发现Invoice Ninja已经存在，它是开源的，而且现成就能提供他需要的90%功能。而且是免费的。Invoice Ninjaexisted, was open-source, and did 90% of what he needed out of the box. For free.
那通电话一直萦绕在我心头。因为老实说，我也犯过相反的错误。Seahawk在2019年有个项目，我们花了8个月拼凑5个不同的SaaS工具——Airtable、Zapier、Typeform、HubSpot和一个定制的Webflow CMS——来管理一个客户工作流。回过头来看，花1.5万英镑做一个定制开发本来可以干净彻底地解决问题。到最后我们每月要为这些订阅付约900英镑的费用。算一算三年的成本。
两个极端都不是自动正确的。任何人如果向你兜售干脆的规则——"总是自建"或"永远别自建"——他在卖什么东西。所以这是我在创始人坐下来问我这个问题时用的真实框架。
---
首先，承认你真正在决定什么
这不是技术决策。严格来说不是。这是穿着技术外衣的商业决策。
当你说"我应该自己构建还是购买？"时，你实际上在问的是：我产品中的差异化优势在哪里？如果你考虑构建的东西是你竞争优势的核心——是让客户选择你而不是选择浏览器中下一个标签页的原因——那么自己构建可能是有意义的。如果它是基础设施、管理工作或商品化功能，购买几乎肯定在实际成本上更便宜。reasoncustomers 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 Reporthas 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.
- Franken技术栈复杂性。五个通过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人的代理公司进行了审计，发现他们每月在SaaS上花费£3,200，这些工具要么已经停用，要么只被用于某个功能。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年没人应该自己构建支付处理器。Postmarkor 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 Huntand G2 are genuinely useful here — not as gospel but as a starting inventory.
问题3：你的现实上线时间是多少？
SaaS工具可以今天上线。自定义构建至少需要数周，通常需要数月。如果速度很重要——在早期阶段公司中几乎总是如此——购买可以为你争取时间，让你在承诺构建之前弄清楚你实际需要什么。
早在2022年，Seahawk与一家物流初创公司合作，他们想要一个自定义的路线优化仪表板。我们说服他们先使用白标API层（他们以Route4Me作为起点）。六个月后，他们确切知道客户真正关心的三个功能是什么。他们最终委托的自定义构建范围缩小了一半——但效果好了一倍——因为他们在生产环境中学习了，而不是在规格说明书中。Route4Meas 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 定价实际上比自主开发更贵。按你预计的第三年使用量算一下数字。有时候定制在纯经济学上更划算。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%。这是乏味的建议。但它也是最常奏效的建议。
---
常见问题
我如何知道我的用例是否真正独特到足以证明自定义构建的合理性？
老实的回答：大多数不是。先花一个认真的下午——我指的是四五个小时，不是二十分钟——列举你所在类别中的每个SaaS产品。如果你已经这样做了，而且没有任何东西满足你的核心需求，问问自己这个需求现在是否真的必要，或者它是你提升为阻碍的锦上添花。如果它真的必要且真的无人提供，那就是一个值得认真对待的信号。necessary right nowor 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这样的运营系统,为你提供了定制软件的灵活性,初始构建成本显著降低。代价是:你仍然拥有基础设施,你仍然需要有技术的人来管理它。它不是免费的——只是启动时更便宜。Metabasefor 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.
---
最后的想法
自己构建与购买的问题没有一个通用答案。它有你的答案,特定于你的阶段、你的团队、你的竞争地位,以及你迄今为止实际验证过的东西。youranswer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
我想反驳的是围绕构建的浪漫主义。定制软件本身并不比一个配置良好的SaaS套件更严肃、更可扩展或更令人印象深刻。我一开始提到的那位开票创始人?他最终确实构建了一些真正定制的东西——但只有在十八个月使用Invoice Ninja教会他他的客户实际需要什么之后。等待让这次构建更有价值。
从无聊的选项开始。通过使用赢得构建新东西的权利。