It's not as applicable to startups as you would think. The real calculation startups are making all of the time that this book doesn't mention is "is it worth making this particular piece scale/secure/robust before we run out of money?"
While it's technically true that the advice would apply to startups in the sense that it would improve their reliability, the elephant in the room is that it doesn't matter. The engineering skill at a startup is understanding what's actually critical, and this book doesn't speak to that.
The "is it doing X before we run out of money?" question is way overblown in startup land, usually by product people to skew developer time towards more features instead of much needed foundational work.
In reality, this question is almost always instantly answerable. You're either still building out your MVP and desperately need customers to validate your idea, in which case the answer is "No", or you're an established startup with runway and a growing customer base, in which case the answer is "Yes".
This doesn’t line up with my experience in startups. Security is never taken anywhere as seriously as all of the best practices (including this one) suggest. Same for cicd, etc.
Best practice is the "best" practice, not the "most common" practice. The thing that sets "best practice" apart from "common practice" is that most people haven't actually done best practice; if they had, they'd just do it again, because it's much quicker and more likely to succeed if you've done it before. And money has nothing to do with implementing things the right way.
I think it's best startups are provided with the most tools/options based on their priorities -- including the underlying lessons this book attempts to deliver - is the right path. Then it's up to their values and priorities.
Ignoring my startup experience (as they are all security-related and therefore took it serious), I believe startups that are handling any amount of customer data should be looking at security very seriously.
Now whether or not they do take it seriously is another problem, that doesn't mean the opportunities and advice shouldn't exist.
Not to be dismissal - but your experience is anecdotal and from the security industry and has no bearing on the reality of running a startup whose business is not security.
>I believe startups that are handling any amount of customer data should be looking at security very seriously.
What you believe has no bearing at all on the cost/benefits of running a business. In the current regulatory environment, leaking customer data in the US costs less money than losing one big customer for a b2b startup. Guess what that means when it’s time to decide to work on a feature for a specific customer or to do a full source code audit of all dependencies for vulnerabilities?
I disagree. There is a valuable question of "how reliable does this system need to be?" and for startups, the answer is often not 5 9s of uptime.
99% uptime is 14 minutes of downtime per day. There are an awful lot of processes and even whole businesses that can eat 14 minutes of downtime a day. Especially if it's not a full outage.
How do you measure "is it worth" without a good idea of the risks and costs involved in the decision making? Just because it doesn't directly answer your question doesn't mean it's not applicable.
In fact, I'd argue the risk factor is significantly different across startups, so exploring the tradeoffs is the only way to approach the problem generically.
(Disclaimer: I work at Google and was involved with some aspects of the new book.)
If your developers, at their core, have been building secure and reliable systems for years, then they can make the new system reliable and secure far faster than a team that always said “there’s no time.” It’s like every skill - you can go amazingly faster, or better, after it gets deeply ingrained after a few years
While it's technically true that the advice would apply to startups in the sense that it would improve their reliability, the elephant in the room is that it doesn't matter. The engineering skill at a startup is understanding what's actually critical, and this book doesn't speak to that.