- 在创业过程中你遇到过技术问题吗？
- 每当你为创业写代码时，总是感到沮丧吗？
- 你要放弃了吗？
别放弃。
你不是独一无二的。
这就是为什么 YCombinator 准备了这个了不起的心态/策略，让你成为成功的技术创业者。
YCombinator（YC）是一家著名的初创企业加速器。他们为早期公司提供种子资金、指导和资源。通过他们的密集计划，YC帮助创业者建立和扩展他们的企业。
进一步了解并蓬勃发展...
技术创始人是指负责创业中的技术/科学方面的人。他们的角色包括构建产品和与用户交流。
在创业初期，技术创始人的角色类似于谷歌等大公司的首席开发人员。你要创新、建设和分发。这也类似于开源项目中的主要开发人员。
你做出所有技术选择。
但是也有一些关键的区别：
-
这是一家创业公司，因此你需要学习并完成所有工作：前端、后端、Devops、各种软件。
-
你将习惯于构建一个足够好的产品，而不是完美的产品。这样你就可以快速推进。
-
你将习惯技术债务和低效、杂乱的流程。
在早期阶段，你只关注成功。尽一切努力使产品运行起来。
现在，你有了一个想法。
这里的目标是尽快构建一个原型。
你可以向用户演示的东西。它不必完全工作。
与此同时，首席执行官/联合创始人将寻找用户，向他们展示原型。
在这里的原则是在几天内非常快速地构建!!!
在一天内构建原型。
怎么做？
使用像 Figma 或 Envision 这样的原型设计软件。让用户可以点击并与之交互。
有一家叫做 Optimizely 的公司。他们的创始人是担任奥巴马竞选运动的分析负责人。他们带着一个不同的想法来到 YC，但没有实现，所以他们在几天内拼凑出了一个原型。他们的原型只是一个带有 JavaScript 文件的可视化编辑器，用于运行 A/B 测试。这已足以展示给他们潜在的客户。
根据解决的问题的复杂性，你的原型可能需要更长时间。
Escher Reality 公司就是一个例子。他们从事增强现实技术，所以他们花了几周时间才得到一个原型。他们必须让计算机视觉算法在移动手机上运行。
一个原型可以避免你解释没有人能看到的理论。
常见错误：
- 过度构建。
- 不听取客户意见。
- 不要太执着于一个想法。以 Optimizely 为例。
- 提出理论而不是实际的原型。
这里的目标是在几天到几周内快速构建一些东西。在极端情况下，如增强现实、人工智能等，可以允许几个月的时间。
你想要构建一个获得客户承诺的 MVP。
真正的承诺是让他们付款，而不是承诺或等候名单。
在你构建 MVP 的同时，原型应该是那个获得等候名单和承诺的。
问题：MVP 阶段招聘是一个好主意吗？
这要看情况，但大多数情况下不好。
为什么？
- 这会减慢你的速度，你必须花一段时间找到正确的思路和正确水平的工程师。
- 你会在你和产品之间留下知识空白。
一个例子是 Justin TV/Twitch，他们有 4 个联合创始人：Justin Kan、Emmett Shear、Kyle Vogt 和 Michael Seibel。Kyle 负责视频流媒体，Emmett 负责数据库工作，Justin 负责网站开发。
这已经足够让他们启动后再去招聘。但他们选择了不合群的人。他们选择了谷歌拒绝的人。他们选择了可以迅速展开工作并独自进行项目的人。
#1 做那些不容易扩展的事情。
暂时不要担心扩展。
手动加入、手动编辑数据库以添加用户和条目、疯狂的客户支持。现在仍然允许所有这些。
只需阅读 Stripe 的 MVP 故事。他们会用银行表单手动填写请求，通过他们丑陋的网站和 API 进行提交。这不可扩展，但它使他们有足够的时间生存下来，最终实现了可扩展性。
#2 创建一个 90/10 的解决方案。
总是希望用 10% 的工作/努力/时间达到 90% 的目标。- Paul Buchiett，Gmail 的原始发明人。
创建一个能用的东西。削减那个庞大的创业项目，然后再次削减，并构建剩下的部分。你可能需要以后重写整个代码库，这没事。
一个很好的例子是 DoorDash，他们的 MVP 只是一个 HTML/CSS 静态网站。他们的网站上有一个创始人的电话号码。后端是一个 Google 表单。他们通过 Google 文档协调订单。他们使用 iPhone 上的 Find My Friend 来跟踪司机。
很糟糕，但它有效。
#1 平衡适合你的产品和技术专长的选择。
选择一些可以让你快速前进的东西。不要选择一些新奇的无用的东西。我在尝试构建我的第一个 SAAS 时犯了这个错误，我也受了伤。
#2 根据迭代速度选择技术栈。
使用第三方库。
- Auth0 用于身份验证
- Stripe 用于付款
- React Native 用于跨平台
- AWS、Vercel、GCP 用于云端
- Webflow 用于落地页
- Firebase 或 Lambda 用于后端
你不需要为这些需求构建自定义解决方案。创业公司因为试图从零开始构建一切而耗尽时间和金钱。
人们抱怨可伸缩性和成本的问题。但现在不是担心可伸缩性的时候。如果你担心成本，有很多开源版/付费版/免费版本的替代品。
你甚至可以编写糟糕的代码。以后你会有时间解决它。
Facebook 最初是用 PHP 构建的，事实上 PHP 是无法扩展的。经过足够的增长后，他们构建了一个编译器，帮助他们将 PHP 转换为 C 代码。这解决了他们的速度问题。
#3 唯一重要的技术选择与你对客户的承诺有关。
Escher Reality 抛弃了他们的许多代码并进行了重写。他们对客户承诺保持了 APIs 和 Unity 引擎插件的工作。他们通过不触碰这些承诺来履行承诺。
这里的目标是迭代以达到产品市场适应性。
#1 用硬数据和软数据迭代快速
硬数据是你实际在仪表板或电子表格中追踪的数据。
软数据是关于你的产品的对话中获得的数据。可以是与客户或投资者的对话。
确保有一个跟踪硬数据的分析仪表盘。使仪表板简单。选择速度。只使用 Google Analytics。
将硬数据和软数据结合起来，了解为什么用户保留或流失。
找出用户的新问题，并首先解决这些问题。
一个很好的例子是 WePay，这是一个 B2C 的支付解决方案创业公司。他们拥有所有 B2C 功能，例如邮件、等等，但他们的用户并不使用。他们的主要用户是 GoFundMe，后者也告诉他们他们只需要付款。创始人们将这视为进入 API 产品的机会，这就是他们达到产品市场适应性的方式。
#2 持续发布
Segment 是一个课堂分析解决方案。他们最初只有 Google Analytics 插件。然后，他们决定倾听用户的意见，并开始为 Node、PHP、WordPress 等添加支持。
他们每周都在发布。最终他们以 30 亿美元的价格出售。
#3 平衡构建和修复。
适应技术债务。
你可能需要构建更多而不是修复错误。
一个例子是 Pokemon Go 在 2016 年推出时，用户甚至无法登录游戏。即使如此，他们也没倒闭。
他们有一个错误。他们的架构还没有准备好应对游戏获得的用户数量。就像他们遭受到 DDOS 攻击一样。他们花了一个月的时间才达到 Twitter 10 年所拥有的活跃用户量。这对他们的架构造成了压力，但他们仍然成功了。
事实上，他们去年的营收超过了十亿美元。
下面的图表总结了在这个阶段的错误。
此时，你要为可扩展性而构建。
此时，代码重写和优化开始发挥作用。
在这个时候，技术会因为需求而崩溃。
你将决定工程文化将会是怎样的。
