尽管大多数程序只有寥寥几个用户，尽管大多数服务端一天的 PV 不过百，可讽刺的是，天底下大部分教材都在教你怎么写用户上千万、PV 过亿的程序。

这就好比，你每天只能摘到一粒葡萄，可老师教你的是如何制作大型榨汁机好在五秒钟内榨完一大筐葡萄。

初创公司最开始要的是一个 MVP（最小可验证产品），这种东西只要能把流程走通，验证了想法，就足够了。

MVP 是验证需求真伪的最佳工具，而它验出的结果十有八九是：这是个伪需求。

没错，MVP 带来坏消息远比好消息多（前提是创始人客观理性、不故意歪曲事实）。不过换个角度想，MVP 带来的坏消息能帮你在前期纠错止损，为以后真正该做的事保留战斗力，所以坏消息其实是有益的。

有个做技术的写了本创业指导书 Hello, Startup: A Programmer’s Guide to Building Products, Technologies, and Teams。我看了其中一部分，写的真挺不错，亚马逊上评价也很高。但是他关于技术部分的建议，对于大部分创业者来说，仍然太过复杂了，不利于快速验证想法。

速度有多重要，举个例子来说，假如你有一个 idea，原型要三个月才能做出来，那意味着什么呢？创业的冲动很可能在这“漫长”的三个月中湮灭了。就没有然后了。

假如速度提高到一周就出来原型，那意味着什么呢？稍微咬咬牙，从零到一就有了！然后才有试错的资格，才有后面一切的可能。

为了把开发速度提高再提高，应该给初创公司几点建议：

1. 做技术选型，开发效率比运行效率重要
2. 选择社区成熟的技术，有一大堆现成的库和解决方案
3. 技术不要追新，除非这项新技术本身是最大卖点
4. 只要一台服务器，或者干脆不要服务器
5. 加缓存等任何提高性能的事，统统不做
6. 忘掉数据库设计范式
7. 忘掉测试驱动开发，要知道现在是 MVP 驱动开发
8. 能买现成的就不要自己开发，一般来说时间比钱重要

如此反传统的做法，并不是要牺牲用户体验。因为在最开始没几个用户的时候，不会出现高并发带来的性能问题。如果这是一个重用户体验的产品，比如目标用户很在意设计风格或者等待时长，那该下的功夫还是要下，但仍然和高并发没有半毛钱关系。