That might have been true 20 years ago but today basic development practices are a solved problem. Any competent senior developer knows what to do. There's no need to start with chaos and repeat the same unnecessary mistakes.
It's a solved problem for a given problem domain. The "best practices" for software development depend very heavily on which particular industry you're writing software for, and senior developers in one industry are basically incompetent when it comes to working in a different industry. I've worked in finance, I've worked on search, I've worked on casual Javascript games, I've worked in compilers & devtools, and I've worked adjacent to people who are doing avionics. There is no way in hell I would apply the development best practices for Javascript gaming to making a plane stay in the air, and similarly there is no way in hell I would apply avionics standards to casual games.
The point is that in a tech startup, you are attempting to solve a previously unsolved problem. If the problem has already been solved before, why shouldn't your customers just use the existing solution? And there's a generic set of best practices for startup coding, but it basically amounts to "Do absolutely nothing that doesn't help you validate the key unknowns of your business hypothesis." Basically if you know that something is going to work, you shouldn't be doing it - you should be integrating the library/service/tool that already does it, or hiring the person that's done it before.
The vast majority of software startups are attempting to solve previously unsolved business problems using mostly the same technology stacks as everyone else. The basic principles of CI/CD are pretty similar regardless of language or tooling, and should now be understood by any competent senior developer regardless of whether they work in gaming or avionics or whatever. Applying those CI/CD principles absolutely helps with validating the key unknowns of your business hypothesis; it doesn't waste time, it saves time even at the beginning.
There will of course be some outliers where these best practices don't apply, but I assert that those are very rare. Most startups aren't special.
Sure. If the technology involved in your software startup basically involves putting a web or mobile app in front of a Rails/Django/Node appserver in front of a RDBMS or equivalent NoSQL database, and the primary business questions are "What data do we need to store, and how do we present it to the user?" then getting your CI up is important. This was a large fraction of viable startups from 2005-2013, so it certainly was a large number of startup jobs.
However, my experience is that those opportunities are largely getting tapped out, and the ones that still exist in the market today are increasingly niche. Between YC & accelerators, services for startups (Clerky/Gusto/Stripe/AWS/etc.), availability of capital, and the amount of open-source software available to build systems, it's become incredibly easy to found a startup - which means that lots and lots of people have, and picked clean most of the markets where a viable product can be made by gluing together these components.
Continued success under capitalism means doing new things that haven't been done before. The web, mobile, and tablet were new platforms that opened up computing to huge new markets. However, all the new platforms since 2010 have fizzled and failed to get mass adoption - wearables, realtime web, AR, VR, cryptocurrency. That leaves tech startups founded today trying new things, either leveraging AI & data science for new insights, trying to get access to increasingly unruly data sources that have not yet been tapped, exploring variations on blockchains & cryptographic proofs, or combining various platforms & libraries in new ways to find new uses. All of these take a lot more experimentation and have much less defined best practices than web and mobile development, but the potential upside is much higher than leveraging a database-backed webapp to solve a new set of business problems.
Just because you change the acronyms doesn't mean that you can completely forget about CI/CD. It's still relevant. Even more so with the newer technologies. You'll probably use different build tools and testing tools. But everything else is still the same.
You will, and I'm certainly not objecting to the use of CI once you know what product you're building and what its architecture will look like. But the whole point of this discussion is that you don't know that in this phase of startup development. There is a non-trivial chance that you will have to swap out your entire tech stack or drop whole components from the product. Building extensive infrastructure around code that gets run 2-3 times and then deleted entirely is a waste of time.
If you've started building software that you're going to have scrap that quickly, your problem isn't with the tools. You've messed up big time with planning. Either way, you're still going to need CI/CD.
I'd agree that most are but if you move into scientific computing startups the problem domain is much different and
CI is a nice to have. It's much more about R&D.
It's not really free - for CI to be useful you usually need a test suite to run, particularly with the interpreted languages like Python that are commonly used for scientific or exploratory programming. Test suites are a waste of time when you can't define what the expected behavior is, and we're talking about a particular problem domain where the goal is to find the expected behavior.
