I get the argument, but one of the reasons Google has a bigger-than-a-whole-startup team to maintain Blaze is their build tool needs to do a whole bunch of thin

I get the argument, but one of the reasons Google has a bigger-than-a-whole-startup team to maintain Blaze is their build tool needs to do a whole bunch of things. At a startup, your build tool just needs to build your product, not a thousand different products in fifty different tech stacks that all use them slightly differently. Sometimes, your product will look close enough to an existing internal Google product that you should just use Bazel and call it done. Sometimes it won't, and maybe it makes sense more to write some really good build tooling than to coerce your product into being shaped like someone else's so you can feasibly write glue code. At the 50-person company I worked at 6-8 years ago, my team's product was custom Ubuntu-based OS images that booted appliance-style on customer hardware and ran our product full-screen. We had some very nice tooling based on the live CD creation stuff that would a) build our cross-platform code into Debian packages b) patch and rebuild a couple of Ubuntu packages, or fail the build c) generate a nice OSS compliance bundle and d) output a .iso as well as a directory of .debs for internal interactive testing (so you could upgrade a machine you'd already installed without reinstalling it). We wrote some small custom tooling to snapshot the Ubuntu repo metadata periodically (https://github.com/mokafive/apt-mirror https://github.com/mokafive/apt-mirror) and build using the snapshot as of the time the SVN branch was created. Keeping this system running, once it was built, took very little time - that project was briefly down to one engineer and I could keep writing code and trust the build system to work fine. If I needed to implement that today using the best commodity tools I could, I'd probably be in some sort of Dockerfile hell, and in fact I'd probably be strongly inclined to design the customer system on top of Docker somehow, even though it would be absolutely the wrong fit, simply because that's what everyone else's OS-image-building problems look like these days. I guess the flip side is that there are probably few startups building products like that, and many more startups where you're building a CRUD app in Rails^WNode.js and your value to the customer is that you're just doing a really good job of writing a CRUD app. That's fine and valuable, and there's an interpretation where it's my personal failing that I'm not really excited by that, even if it's delivering business value / helping the world / etc.. But it is how I feel (and my guess is the author feels the same way), and I once did leave a company because I felt, for lack of a better term, bored - I was having to invent my own opportunities to grow as an engineer, and it was made clear to me that I would get better performance reviews if I worked on less ambitious projects. And when I've been interviewing people at my current place, I've heard enough stories of people being equally bored at their current jobs at large companies. So - this isn't a BigCorp vs. startup argument, I think. It's an argument that different companies have different levels of appetite for build-and-encourage-internal-tooling vs. buy-and-conform-to-the-outside-world in their culture, and if you're an engineer who's going to be frustrated by the latter, look for a company (of any size) that believes in the former.