本篇想记录的内容就比较偏技术了，准确的说应该是偏服务端一点。
按理说，产品功能大致定了后应该是轮到组队找小伙伴了开始。因为找人这事很大程度上牵扯到的因素太多，比如你产品的类型，人脉，创始人的身份，资金，甚至是运气。我也一时不知道该从哪个点切入来谈自己的感受，所以先略过。不过我有一点感受还是挺深刻的，在我心目中，如果要给资金，人，产品这三个条件排个序的话，我会毫不犹豫的选择人这个因素，很多团队来队员陆陆续续加入的过程中其实已经给之后爆发的问题埋下伏笔了，永远要记住“在你条件允许的情况下，找最优秀的人，千万不要妥协！”。宁可因为没有合适的人而放缓一下产品节奏也是可以接受的。
回到本篇的主题，我这里所说的技术选型一般是分两方面的，对于APP来说也就是 客户端和服务器端。
客户端就比较简单了，因为就三种类型，Native，HTML5, Hybrid.我就一句话带过"具体的子功能分别选择合适的实现方式"，一般类似活动这种多变的功能我们就会选择HTML5，我们自己实现了一套协议，能够在应用内让HTML5跳Native页面,这样你该灵活的地方基本可以发挥到极致了。
服务器端牵扯的事就多了，总结起来还是一句话，"能放到云端，不用自己做的就千万别去造轮子".不过从这单上来看还是不分web和app的，互联网产品追求的还是快速迭代，快速验证需求这样一个循环，"唯快不破"这一招用在哪都不会错。如果我们拿一款社交APP来举例子，我现在的选择会是这样的。
核心功能这里不讨论，一般这种还是要自己造一定量轮子的。
利益不相关!纯主观!
聊天:环信 www.easemob.com.如果对聊天数据敏感，就选择一套市面上的推送服务，使用心跳加推送来实现.
图片存储加处理:七牛 www.qiniu.com .客户端，服务器端，多种上传模式，多语言SDK。几乎能满足你大部分图片处理需求的云处理方案.现在还支持国外的cdn服务了。
推送:太多了，我们用的是极光推送。
服务器:国内阿里云，国外AWS.
数据库:MongoDB,原生支持LBS查询,上手简单，为集群而生。
开发语言:python，上面说了要(迭代)"快",还有什么好解释的.
以上每点就不深入探讨了，因为工具是死的，还是感叹下，你用对了人"那都不是事儿"。
网友评论