月成本 20 美元，养活多家万元级订阅公司：一个独立开发者对抗“云账单崇拜”

硅谷创业叙事这些年有点像套餐销售：先上云，后容器；先配 Kubernetes，再谈数据库；AI 产品还没找到用户，账单倒是先按企业级标准起飞。于是，很多创业者还没证明自己能不能赚钱，就先学会了怎么把 AWS 控制台点出一张让人心跳加速的发票。

加拿大开发者 Steve Hanov 最近写了一篇文章，标题直接得像一记直拳：《How I run multiple $10K MRR companies on a $20/month tech stack》。翻成大白话就是：我用每月 20 美元左右的技术栈，跑着多家月经常性收入过万美元的软件公司。更有意思的是，他去参加融资活动时，得到的反馈不是“产品不行”，而是“你都已经有收入了，到底还融资干什么？”

这句话听起来像玩笑，但也精准戳中了今天科技行业一个微妙现实：当“高增长、高估值、高烧钱”被默认当作创业正途时，那些安静赚钱、低成本运转的小公司，反而显得不合时宜。Hanov 的文章之所以引发共鸣，不只是因为他会省钱，而是因为他展示了一种越来越稀缺的能力——用极简技术做出真正有人付费的产品。

创业公司不一定要先长成“企业级样子”

Hanov 的核心主张很简单：别把基础设施当成产品本身。他几乎是带着一点嫌弃地批评了现代 Web 创业的“标准起手式”——AWS、EKS、RDS、NAT Gateway，一套组合拳打下来，用户还没来，月账单先冲到几百美元。对很多习惯了云厂商最佳实践的人来说，这套流程似乎专业、可靠、可扩展；但对一个还在找产品市场匹配的小团队来说，它更像是用机场塔台的标准，去管理一家刚开张的奶茶店。

他的选择是回到更朴素的方案：一台每月 5 到 10 美元的 VPS，Linode 或 DigitalOcean 这种老派服务商就够了。1GB 内存听上去寒酸，可如果你的服务是认真设计过的，它并不一定不够。这个思路并不新鲜，早年大量独立开发者、论坛站长和 SaaS 创业者就是这么起家的。真正新鲜的是，在今天这个“没上云原生都不好意思发招聘启事”的环境里，居然还有人公开说：复杂基础设施可能根本不是必要条件。

这件事为什么重要？因为过去几年，创业技术栈被一种“预防性扩张”逻辑绑架了。团队总在为未来 100 万用户做准备，却没先证明眼前 100 个用户愿不愿意掏钱。技术债当然可怕，但更可怕的是收入债——产品还没建立起正向现金流，基础设施成本就已经形成持续压力。Hanov 的做法，本质上是在把创业顺序重新摆正：先活下来，再考虑优雅地扩大规模。

Go、SQLite 和单机哲学：被低估的“土办法”其实很现代

Hanov 在后端语言上选择 Go，理由也很务实：内存占用低、性能稳定、单二进制部署方便，而且在他看来，对大模型来说也更容易“理解”。这句话初听有点像段子，但放在今天 AI 辅助编程已经渗透进开发流程的背景下，倒并非没有现实意义。你把一个项目交给 Copilot、Claude 或其他代码助手接手时，项目结构越简洁、依赖越少、类型越明确，AI 确实越不容易胡来。

更有争议，也更有意思的是他的数据库选择：SQLite。是的，就是很多人印象里“只能做本地小工具”的那个 SQLite。他的观点是，大多数创业项目初期根本不需要一套远程数据库服务器，本地 SQLite 文件加上 WAL 模式，读写性能和部署便利性都足够出色。某种意义上，这像是把数据库从“要单独供起来的基础设施”降级成了“应用的一部分”。

如果你是传统后端工程师，看到这里可能已经开始皱眉：并发呢？备份呢？迁移呢？多实例部署呢？这些问题当然都成立。SQLite 不是银弹，也不适合所有场景。你一旦进入复杂多节点架构、跨区域部署、海量写入或重事务协同，它的天花板会很快显现。但 Hanov 的重点并不是说 SQLite 比 Postgres 伟大，而是提醒人们：很多人讨论的是“未来可能出现的问题”，而不是“今天真实存在的问题”。

事实上，这几年 SQLite 的地位正在悄悄回升。从边缘计算到本地优先应用，再到一些轻量 SaaS 产品，开发者重新发现了“少一个服务，就少一种运维负担”的价值。业界甚至已经出现了围绕 SQLite 做分布式复制和云托管的方案，比如 LiteFS、Turso 一类产品，说明这条路线并非异想天开，而是在被越来越多人认真探索。

把 AI 成本从“按次付费”改成“买断制”，是个很聪明的创业动作

Hanov 另一个颇有代表性的选择，是把长时间、大批量的 AI 任务搬到本地 GPU 上跑。他用一张二手 RTX 3090，通过 Ollama 和 VLLM 处理股票研究、财报总结这类耗时任务，而不是把所有请求都丢给 OpenAI API。这个思路其实非常像传统制造业里的一个决定：到底是长期租机器，还是干脆自己买一台。

在今天，AI 创业者最容易忽略的，不是模型能力，而是成本结构。很多产品 Demo 看起来很漂亮，背后却是按 token 计费的高额支出。一旦提示词有 bug、批处理要重跑、用户量稍微上来一点，单位经济模型就会迅速恶化。Hanov 的办法很粗暴，但有效：需要反复试错、可离线处理、对实时性要求没那么高的任务，尽量放在本地 GPU 上。一次投入，后面就不必每次都向模型厂商“交过路费”。

当然，这套打法不是零门槛。你得会部署模型服务，得接受本地机器的维护成本，也得理解哪些任务适合本地模型、哪些必须依赖前沿闭源模型。所以 Hanov 的方案其实采取了双轨制：重批处理任务用本地，用户侧高质量低延迟对话则走 OpenRouter，对接 Claude、GPT 这类顶级模型，并顺带做故障切换。这个思路很像一家精打细算的小工厂：大部分工序自己做，只有最难、最关键的环节外包给顶级供应商。

这也是我觉得这篇文章最有现实感的地方。它并不反 AI，也不反云，只是反对那种“默认把最贵的方案当成唯一方案”的思维惯性。创业者最该优化的，从来不是技术时髦度，而是每一美元成本背后能不能换回真实价值。

当 VC 不喜欢“太会过日子”的创始人，这恰恰暴露了行业偏见

Hanov 在文章开头写到，自己又一次在融资活动前筛中被拒，理由居然是：你到底需要融资做什么？这句话表面上像对他盈利能力的夸奖，实际上也揭开了风险投资逻辑里一个不太会被明说的事实——VC 喜欢的是可以放大资本杠杆的公司，而不是已经学会自给自足的小生意。

从投资回报的角度看，这不难理解。一个靠低成本持续盈利的 SaaS 业务，可能是个优秀企业，却不一定是理想的风险投资标的。它增长未必爆炸，组织未必会迅速膨胀，创始人也未必愿意为了讲大故事去大把烧钱。可问题在于，过去十几年，科技媒体和创业文化把“融资成功”塑造成了某种近乎唯一的成功标准，以至于很多年轻创业者下意识觉得：没有云大单、没有豪华团队、没有一轮轮融资，好像就不算认真创业。

Hanov 这篇文章最值得读的地方，就在于它提供了另一种样板：不靠巨额融资，不追求堆人堆云，也能做出用户每天依赖、并愿意持续付费的产品。这种创业方式没有那么热闹，也没那么适合在台上讲故事，但它更接近做生意的本质。

不过，话也得说回来，极致精简并非总是美德。单机架构、极小团队和成本压缩，会不会拖慢产品迭代？会不会把关键风险过度集中在创始人个人身上？当业务跨过某个临界点之后，过去省下来的每一分钱，会不会在迁移和重构时加倍偿还？这些都是值得认真思考的问题。Lean 不等于永远小，低成本也不该变成拒绝必要投入的借口。

也许我们该重新尊重“能赚钱的小公司”了

如果把这篇文章放到 2024 以来的技术环境里看，它其实踩中了几个大趋势。第一，云成本焦虑正在上升，越来越多公司开始重新审视“默认上公有云”的必要性；第二，AI 编程工具让小团队的产出能力明显提升，一人公司和两三人团队正在迎来新的效率红利；第三，高利率时代之后，资本市场对“增长换亏损”的耐心已经不像从前那样无限。

在这样的时点上，Hanov 的实践会被放大，不只是因为它省钱，更因为它符合一种新的创业气候：大家开始重新关心利润、现金流和可持续性。某种程度上，科技行业正在从“融资驱动的浪漫主义”，回到“经营驱动的现实主义”。

我尤其喜欢他文章里那种不太修饰的语气：服务器的目标是响应请求，不是维护基础设施；架构应该服务业务，而不是反过来让业务服务架构。听上去朴素，却像一句很多行业人需要重新复习的常识。

如果说这篇文章会留下什么余波，我猜不会是所有人都跑去把 Postgres 换成 SQLite，把 AWS 删号退订。真正可能发生的变化是，更多开发者会开始问自己一个更尖锐的问题：我现在用的这套技术栈，到底是因为它真的适合我的业务，还是因为它看起来像一家“像样的科技公司”该有的样子？

这个问题，可能比省下多少服务器钱，更值得被认真回答。