@CheungKe 作为创始人之一，确实可能拿比较低的工资。事实上很多投资人也会要求对创始人的工资做限制，这个主要是避免创始人拿了投资直接通过各种方式分了……
不过坦白说啊， 2 个点有点少，当然，这也要看你在团队中是什么角色，投入的精力有多少。

在正常公司的话， 10 元行权价，两年成熟， 6 个月试用期都是没有问题的。
但是压低工资并不好，期权只是补充，能不能受益多少都是无法确定的。公司前期，因为拿了股票而接受低工资的，应该只限于创始人，初创合伙人，最多再加上非常核心人员

看起来很不错啊，可惜 Java 好久不碰了，绑定一下，以后有其它方面需求要继续来这里知会大家一声啊。

大牛们通过助理或者运营团队来观察微博，你还得招到对应的团队才有相同的体验啊。

@loading 自从换用自己的内核之后，安卓版微信的内置浏览器坑太多了，还好 iOS 版受到苹果的限制不能瞎搞。

严格来说，看合同或者员工手册有没有写。

@sun1993 嗯，工作证明什么的也都是公司，但是涉及到人事关系的，比如三方之类的，基本都要靠中智或 Fesco ，因为这些单位是没有接收档案的权力的。

北京所有的外企的正式员工，人事关系无非也就是落在中智或者 Fesco 吧，正常。
官府的政策如此

@BSD 光是用户量级大并没有用啊，要看能不能把用户量变现啊。
如果视频收费，上了年纪的这部分受众很多并不习惯电子支付。我做了好些个网站，发现上了年纪的用户，用到微信已经算是最复杂的应用了，要再使用各种支付方式实在比率太低。
另外就是支付意愿， 30 岁左右的人，和 60 岁左右的人，对例如每个月支付 10 元来看视频的感觉是完全不同的。
最后，如果通过广告变现，什么样的广告主会把广告受众定位于老年人呢？老年人他看到广告会去点击么？就算点击了他会下单么？

所以，在商言商，对商家来说，这是一个投入大，而可能产出小的项目。
类似这种情况，在很多传统文化领域都会存在，靠商家来做是不现实的。这种时候本身就是国家应该做的事情，集聚起社会的资源，做一些没有人能做或者没有人愿意做的事情。

其实这种东西，我在外包也能碰到，你说多少钱合适呢？不同的需求会有不同的架构，几千到百万都是小意思。
觉得简单，那么就做精细点，超市进销存，如果网店多了呢，权限怎么管理？架构能不能撑得住？多个终端同时扣减库存的时候，能正确处理么？
说到底，大多数系统就是 CRUD ，但是高下差太多了。学校的要求可能低，但是自己对自己要求要高啊。

一共有三个时机，一，放入购物车，二，生成订单，三，付款。
我现在一般是生成订单时减库存，订单生成 60 分钟后如果没有付款订单自动取消恢复库存。
生成订单时如果发现库存不足，就提示用户。

选些 baas 的服务呗，比如国内 LeanCloud ，国外 Firebase

@gzelvis 我认为你需要的不是一个牛逼的 iOS ，这不是 iOS 开发人员需要做的，你需要的是一个牛逼的架构来做你的技术合伙人，它能把你的整个后端合理的架构起来，然后带上一两个熟练地 iOS/Andorid/后端的开发就可以了。

两个人应该是可行的，你这 8 个月时间很充裕了。
自己不懂的情况下，找个技术合伙人是对的，技术选型，服务器放哪里，怎么放，都是需要交给更专业一点的。
至于这个技术合伙人需要什么程度，这要看你对 app 的期望有多高，预估的流量有多大。一两个服务器能解决的 app ，和需要一堆服务器协调解决的 app ，表面上看功能差不多，后台的架构会非常大。
最后，找合伙人还是能面对面的那种比较好，所以还是说一下自己的坐标比较合适吧。

看情况啦，不过一般放公网的系统哪怕再小最好这样，不用暴露数据库本机不是。数据库服务器的防火墙只需要给那个提供数据服务 api 的机器留个口就行。如果客户端程序访问数据库，那就要求数据库服务器暴露给所有的客户端啊。

另外，方便扩展，方便前后端分离，方便支持更多平台也都是很好地结果啊。

用户量千万级没什么意义啊，考虑的应该是日活用户量，平均在线时间什么的啊。
我不熟悉 discuz ，但是从架构上来说，如果你是超大同时在线量，架构肯定要重新整的啊，各种拆分，队列，消息，如果 discuz 本身没有，还不如从头做。

谢谢大家了啊。