技术管理的作用是协调各个端的交互和接口规范，还有项目开发里程碑和任务安排 （注意不包含架构，在初创快速实现的强烈需求下，架构先不考虑）。我们不可能让专职后端来制定APP端的里程碑，同样也不能够让专职APP客户端来定后端的里程碑。必然会有一个技术比较全面的枢纽人物，我认为这是项目快速推进的基础，同样也可以负责测试和code review。尽管这和产品经理有点类似，对于产品规划较全面的初创来说，是可以合二为一的。出于成本考虑，我们需要低成本招到这样的人来统揽项目技术全局。
后端在产品体系中属于重合度最高的端，需要和每个端产生交互，最低成本的方式是将技术管理这部分成本附加到后端，说人话：“找一个符合前面所述开发要求的全栈后端来承担技术管理工作”。
个人总结（按照通用水平，大神级别的不在讨论范围内）：
对于专职后端：Laravel 人工成本要略低于 Spring Boot
对于技术管理：脚本系（PHP、Python、JavaScript）的猿往往更容易向全栈发展，J2EE 这种企业级巨无霸框架，分工概念很强，比起脚本系语言全栈工程师就显得更少。而且既能胜任J2EE+Spring Boot 开发，又是全栈的猿，初创还是不要考虑了，太贵。
从PHP猿中找到符合初创技术管理要求的，概率要比从Java猿里面找高一些，参考对象多，议价能力自然也高些。
在不考虑系统架构优劣的前提下，人工成本方面 Laravel 比 Spring Boot 更有优势
最后再多嘴说一句初创的软件系统架构问题：我接触过很多初创，而且还把软件系统架构看的很重，这是一个严重的误区。正如网友们说的，Laravel 存在性能问题，为了做大之后流量大了服务不挂掉，嚷嚷着要上微服务。
产品上线了没？产品都还没上线，要啥高并发，要啥高性能，要啥微服务。
初创项目一般流量不大，也不是计算密集型服务，性能瓶颈不会是在PHP框架本身，没有必要纠结是 C/C++和JVM谁执行速度快，PHP比C慢了多少个数量级，这些毫无意义。当你有了这个性能需求的时候，如果公司还没那个资金去高薪找人才，那商业模式真的是没谁了！
还有微服务，一个街边小摊嚷嚷着要按照阿里巴巴的运营模式来搞，其实这样没啥问题，自己选的路，冷暖自知吧。微服务天生就是分布式，分布式本身就是一个非常大的系统，不是初创适合玩的。就像跨国运营战略适合阿里这种体量的公司，因为业务复杂度已经到达了某种程度，经过评估是对公司短、中、长期发展都是有利的。街边小摊套用这种模式，只会被复杂度困住手脚，当然当您的小吃迈出国门，走向世界，手底下几千人，战略模式自然就有了。当软件复杂度和项目业务量到达一定程度，有了服务拆分和分布式需求，微服务自然就有了，初创要做的可能是关注扩展性，并不是微服务。
小流量前提下谈高并发和架构就是耍流氓！您要的可能不是架构，而是扩展性！