跳到正文

让一个业余项目成长到一万名用户

一个周末冒出的想法，慢慢变成了数千人使用的产品。这是我在这个过程中学到的东西。

第一个版本简单得有些让人不好意思：一个单页应用，用 JSON 文件充当数据库。我把它部署在免费服务上，分享给几个朋友。本以为事情到这里就结束了。

后来，它在 Twitter 上受到了关注。突然间，我的“周末项目”有了真实的用户，也承载着他们真实的期待。

最初的一百名用户

最初的一百名用户很好相处。他们耐心、宽容，大多只是带着好奇而来。他们提交反馈、报告问题，即使产品出了故障，也愿意留下来。

在这个阶段，我做了一个关键决定：多听，少做。

我没有忙着添加自认为很酷的功能，而是专注于用户真正需要的东西：更简单的上手流程、更快的加载速度、更清楚的错误提示。这些小事带来了很大的改变。

// 我最初的“数据分析”：只是在控制台记录信息
window.addEventListener('error', (e) => {
  console.log('User hit an error:', e.message);
  // 后来替换成了正式的错误追踪工具
});

一千名用户带来的问题

用户接近一千人时，各种问题开始出现。JSON 文件的方案不再够用，响应时间变长，免费服务也碰到了额度上限。

我必须认真做出基础设施方面的决定：

  • 数据库： 从 JSON 迁移到 PostgreSQL
  • 托管： 升级到支持自动扩容的付费方案
  • 缓存： 为频繁访问的数据加入 Redis
  • 监控： 为服务中断和慢查询设置告警

最困难的并不是技术迁移本身，而是在不影响现有用户的前提下完成迁移。我学会了逐步发布变更，并始终准备好回滚方案。

一万名用户教会我的事

达到一万名用户后，我的视角彻底改变了。在这个规模下，你开始关注的，不再只是功能，而是系统。

  • 可靠性比新鲜感更重要。 应用无法访问时，用户不会在意你刚推出的新功能。
  • 性能本身就是功能。 每多出 100 毫秒延迟，都会损失一些用户参与度。
  • 文档可以节省时间。 当其他人加入时，他们需要理解你做过的决定。
  • 自动化不可或缺。 手动部署无法适应规模增长，CI/CD 流水线可以。

意料之外的挑战

有些事情让我始料未及：

  • 支持请求增长得很快。 即使只有 1% 的用户遇到问题，在一万名用户中也意味着一百张工单。
  • 边界情况会变成常见情况。 那个被你忽略的问题，会有人每天遇到。
  • 人们会用你从未设想过的方式使用产品。 构建时需要保留一定灵活性。

回头看

从零增长到一万名用户，靠的不是多么巧妙的设计，而是持续投入。每天出现，修复问题，倾听反馈，一点点改进。

那个周末项目如今已经成为真正的产品。最大的收获是：从简单开始，但要打下能够继续生长的基础。

如果你正在做一个小项目，不必过度设计，也不要完全忽略未来。思考规模问题的最佳时机，是你真正需要应对它之前。

模板示例

继续阅读