2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
2011年，初创企业基因（Startup Genome）与伯克利大学和斯坦福大学合作，研究了3200家初创企业。他们想知道为什么大多数初创企业会失败。
答案并非糟糕的创意，也不是缺乏资金，更不是竞争激烈。
74%失败的初创企业，其失败原因是过早扩张。在尚未找到产品与市场契合点之前，就增加了复杂性……比如基础设施、功能特性、团队规模、流程等。同一项研究还发现，失败的初创企业在达成产品与市场契合点之前编写的代码量，是成功企业的3.4倍。
请花点时间思考一下：那些最终存活下来的团队，编写的代码更少，架构也更简单；而失败的团队则忙于构建平台。
会议演讲的问题
每一场技术大会的演讲、每一个热门代码仓库、每一篇关于“现代技术栈”的博客文章，都在推动你走向复杂化：GraphQL、微服务、事件驱动架构、客户端组件中嵌套服务器组件，再包裹一层悬念边界（suspense boundaries）。
其中大部分都是在为尚未出现的问题做工程设计。
丹·麦金利（Dan McKinley）——前Etsy公司首席工程师——早在2015年就撰文讨论过这个问题，而这一框架至今愈发显得正确。每个工程团队大约只有三个“创新令牌”（innovation tokens），也就是尝试使用新且未经验证技术的机会。你应该把这些令牌用在产品的差异化功能上……而不是用在你的Web框架、数据库或部署流水线上。
如果你的产品创新点是一个新颖的人工智能功能，那才是你该使用令牌的地方。你的REST API并不需要一个。
那些从“无聊”起步的公司
这些并非假设。
Shopify运行的是一个基于Rails的模块化单体应用。2024年，它在黑色星期五周末处理了1730亿次请求。不是微服务，也不是自研框架，就是Rails。他们在过去18年里不断优化架构，但基础从未改变。
GitHub运行Rails单体应用长达12年。直到2020年拥有1000名工程师时，才开始拆分服务。一千名工程师，仍然在使用单体架构。当他们最终拆分服务时，也是有选择性地进行——并非因为单体无法扩展，而是因为团队规模过大，难以在单体内有效协作。
这才是真正的扩展问题：人，而不是服务器。
Stack Overflow在超过十年的时间里仅靠9台本地服务器运行……一个基于.NET的单体应用搭配SQL Server数据库，支撑了数十亿次页面浏览。他们对此非常坦诚，因为这与业界关于扩展性的主流观点完全相悖。2025年，当他们的数据中心合同到期后，才迁移到云端……但在此之前的15年多时间里，其架构始终是有意保持“无聊”的。
WhatsApp被Facebook以190亿美元收购时，仅用32名工程师就支撑了4.5亿活跃用户。整个工程团队的规模，甚至比大多数A轮融资阶段的初创公司还要小。
“无聊技术栈”的公式
如果你是一名独立开发者或小型团队，正在构建一款SaaS产品……那么“无聊”在实践中具体表现为：
一台服务器，两个应用。一个后端API和一个前端客户端。不需要服务网格，也不需要消息队列。两个进程在同一台机器上通过HTTP通信即可。
一个关系型数据库。你的数据几乎肯定是关系型的：用户属于组织，组织拥有订阅，订阅关联账单。PostgreSQL在过去25年多的时间里一直可靠地处理这类数据。对于那5%真正适合文档模型的数据，它也支持JSON字段。
不要自己实现身份认证。身份认证是一个已被解决的问题，同时也是最不该自行实现的功能之一。会话管理、令牌轮换、OAuth流程、多因素认证（MFA）、密码哈希……每一项都涉及安全风险，稍有不慎就会带来严重后果。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
