在 Reddit 的 r/SaaS 板块有一篇热度很高的帖子。作者和他的团队前后做了 17 个以上的 MVP（最小可行产品），然后得出了一个朴素的结论——
大多数创始人在技术选型上想太多了。
他们把这套技术栈称为 "无聊但赚钱的栈"（The Boring Stack That Makes Money）。不是因为它酷，而是因为它真的能帮人把产品跑起来、收到钱。
这套栈到底是什么
| 层 | 技术 | 为什么选它 |
|---|---|---|
| 前端 | Next.js（React 框架） | SSR/SSG 支持好，生态成熟 |
| 后端 | Supabase | Auth + 数据库 + 边缘函数，一站式 |
| 数据库 | Supabase PostgreSQL | PostgreSQL 够稳，MVP 阶段不需要额外引入 Redis |
| 认证 | Supabase Auth | 开箱即用，不用自己写登录逻辑 |
| 部署 | Vercel | 和 Next.js 无缝集成，免费额度够用 |
| 支付 | Stripe | 接入快，支持全球支付 |
| 邮件 | Resend | 事务性邮件，API 简洁 |
| 分析 | PostHog | 开源，产品分析一体化 |
月成本：约 86 美元。搭建时间：2 小时。能支撑的用户量：百万级。
MVP 阶段刻意不用的东西
这份清单可能比推荐清单更有意思：
- 不用微服务——你不是 Netflix，没必要一开始就拆分
- 不用 Kubernetes——你有 10 个用户，不是 1000 万
- 不用 Redis——PostgreSQL 本身已经够快了
- 不用 React Native——PWA 方案在验证阶段足够用
- 不用 TypeScript——这是最有争议的一条。他们的理由是用 JavaScript 写得更快，等需要规模化了再迁移到 TS 也不迟
关于 TypeScript 这条，帖子里的评论吵得很厉害。有人觉得这是低级建议，也有人认同 MVP 阶段速度优先。我觉得关键不在于选对错，而是你清楚自己为什么做这个取舍。
两个真实案例
作者举了两个客户的例子：
案例一：一个客户坚持要"企业级架构"。微服务、GraphQL，全套上了。花了 8 个月，烧了 10 万美元，最后没上线。
案例二：他的竞争对手用了这套"无聊"的栈。6 周，3500 美元，月经常性收入跑到了 5 万美元。
不是说企业级架构本身有问题。问题是在你还没有用户的时候，花 8 个月搭一套完美的系统——这本身就是一个风险。
他们的一句话原则
你能不能在 30 秒内解释清楚你的技术栈？如果不能，对 MVP 来说就太复杂了。
他们的回答是："应用用 Next.js，数据用 Supabase，收款用 Stripe。就这些。"
几个值得注意的细节
1. 免费额度是真的够用
Vercel 和 Supabase 的免费层对于 MVP 验证阶段确实够跑。Vercel 的 Hobby 计划免费提供服务器端渲染，Supabase 的免费计划包含 500MB 数据库和 5 万月活跃用户的 Auth 额度。等到真的需要付费了，说明产品已经有人在用了——这本身是个好消息。
2. 非程序员也能上手
这套栈加上 Claude Code 之类的 AI 编程工具，没有编程经验的人也能搭出能用的产品。Supabase 的 dashboard 是可视化的，Stripe 的接入文档写得足够清楚，Vercel 部署就是推一下代码。技术门槛比三年前低了不少。
3. 社区的不同声音
Reddit 帖子下面的评论并不是一边倒的赞同。几个有代表性的反对意见：
- "86 美元/月这个数字有误导性，用户量上来后 Supabase 和 Vercel 的费用会快速上涨"
- "这是一篇内容营销帖，目的是给自己的工作室引流"
- "否定 TypeScript 说明作者不理解类型安全在中型项目中的价值"
这些批评有道理，但也别忘了作者的语境——他说的是 MVP，不是长期产品。验证阶段和规模化阶段的考量确实不同。
我的想法
这篇帖子最打动我的一点是它的务实。不是"你应该用什么"，而是"你不需要什么"。
Instagram 用 13 个工程师撑到了 10 亿用户。WhatsApp 用 50 个人撑到了 9 亿。我们大多数人遇到的问题不是技术栈不够先进，而是迟迟没有把东西推出去让人用。
技术选型当然重要，但顺序不能反过来——先有用户在用，再谈架构也不迟。
总结
这套栈的核心逻辑就三条：
- 前后端解耦，前端挂了不影响后端跑
- 免费额度足够支撑到产品市场匹配（PMF）
- 从零到上线，一两天就能搞定
用作者的话说：先做出有人愿意付钱的东西，再去操心技术。