I see this all the time with build systems for various languages and projects (as well as for other classes of tools, frameworks, etc). Most of the time you don

I see this all the time with build systems for various languages and projects (as well as for other classes of tools, frameworks, etc). Most of the time you don’t need the more complex tool. Ride out the simpler tool for as long as you can, and only when your product is mature (the time finding market fit is tremendously valuable—don’t waste it on integrating/building the perfect, most future-proof build system) and successful and you have a backlog of features that really do depend on the more complicated solution do you migrate. Ruthlessly trim that backlog for fade dependencies (most of the time the simpler tool really meets the actual requirements, but proponents of the more complex tool will stock the backlog with items that only appear at first blush to depend on the more complex tool). Consider the one-time cost of moving to the more complex tool and the ongoing increased cost of maintaining the more complex tool (and multiply both by 10) and compare those costs to the value of the items in your backlog, making sure to account for opportunity costs (I.e., what else could my team be working on instead of spending time porting and maintaining the more complex tool?). A sign of engineering maturity is knowing the right time frame to plan for relative to your project’s lifecycle. Don’t worry about how your solution will scale when your product is hugely successful and you have Google-scale concerns; focus on getting to next week or next year or whatever timeframe is appropriate for your product’s current level of maturity.