Build vs Buy：你的时间比代码值钱

写代码容易，但写出能变现的代码很难。在 AI 让编程门槛无限降低的今天，我观察到一个危险的趋势：越来越多的开发者陷入了一种“全能自恋”，觉得凡是需要做的功能，必须亲手敲一遍才有成就感。

这恰恰是困住大多数独立开发者的陷阱。

最无聊的方案，往往是最正确的

如果你需要在 .NET 应用里加个功能开关，答案其实无聊得让人发困：安装 Microsoft.FeatureManagement，在 appsettings.json 里写几行配置，搞定。

这句话揭示了一个反直觉的真相：真正成熟的商业工具，往往长得极其乏味。 boring is profitable （无聊即盈利）。

很多开发者沉迷于自己造轮子，试图打造一个“更完美”的通用解决方案。但现实是，你在 GitHub 上花三个月写的“更好版本的 X”，市场上可能已经站着十个更好的竞品。这不是因为市场饱和，而是因为你的时间成本算错了。

决策前的三个灵魂拷问

下次当你觉得“我要自己写这个模块”的时候，先停下来，问自己三个问题：

1. 有没有现成的开源方案？ 哪怕它只有 70% 满足你的需求，剩下的 30% 是否值得你花两周去定制？
2. 有没有付费 SaaS 能解决？ 每月花 29 美元买现成的服务，和你花 100 小时开发维护一个内部工具，哪个 ROI 更高？
3. 自己造的核心价值在哪里？ 这个功能是你产品的核心差异化竞争力吗？还是只是一个支撑性的基础设施？

如果前两个问题的答案已经是“够用”或“可以接受”，请毫不犹豫地直接用。只有当现有方案严重阻碍了你的核心业务创新时，自建才是正解。

克制力，才是顶级开发者的护城河

我见过太多聪明的工程师，最后沦为“空转者”。他们写的代码很优雅，架构很完美，但产品从来没有跑起来过。因为他们把精力都花在了基础设施的建设上，而不是用户价值的打磨上。

先买，后用，再想有没有必要自己造。

这条规则救过我很多次。独立开发的核心竞争力，从来不是你对某个技术栈的熟悉程度，而是你分配精力的判断力。少造一个轮子，你就多出一小时去研究用户痛点、优化转化流程，或者仅仅是好好睡一觉。

在这个 AI 辅助编码普及的时代，代码本身正在贬值，唯有对“什么该做、什么不该做”的洞察，才是不可替代的资产。