It's kind of like trying to save time on a marathon by not stopping to tie your shoelaces.
I mean it takes maybe a day or two at most to set up a CI/CD pipeline with Github actions or something similar. It takes maybe a day to set up test runners, and you can just sprinkle in small tests as you go. There are plenty of templates you can find depending on your language/platform that do most of this out of the box.
You don't need a perfect pipeline or test coverage, just something you can improve on incrementally. It's much, much harder to do all this on top of a bloated legacy codebase and infrastructure and that's when "adding CI/CD" becomes a Big Project that we'll get to real soon now.
A startup doesn’t have a known course with a finish line and competing forces defined by rules.
A startup is running from a grizzly bear and tying your shoe laces is an engineering decision. There are important tradeoffs and potential bad outcomes either way.
“Continuous integration and testing practices" are useless when you are going to rewrite the software from ground up every year or two years. You just patch the software until it's time to throw it away.
Many startups write something that they can sell, get experience, realize what they should have been doing instead, then do that.
Your team’s velocity will be faster from week 2 through the end of the 2nd year if you build the rapid feedback cycles provided by automated testing and CI/CD into your progress from the beginning
UNLESS your team lacks the experience to build and maintain a test suite with a high benefit-to-cost ratio, which is unfortunately the case for most teams.
In this case I don’t have any good solutions, other than choosing one’s team and teammates carefully, before starting the project.
“Continuous integration and testing practices" are not exactly a great burden, and you don't know when the thing you are working on is going to snowball and become the thing you need to nurture and grow. Even if you pivot, you will likely want to re-use code written for earlier attempts.
I suspect the reason startups don't do the bare minimum here is because their developers tend to be cheaper and less experienced (at least until they get funding), and "we move fast and break things" is just a lame justification for incompetence.
In theory yes, you're supposed to migrate away from the legacy codebase.
In practice I've never, ever, ever seen that happen: it's too much upfront cost to start over, especially when you have real customers and real data on top of it and you need to keep pumping out new features.
I mean it takes maybe a day or two at most to set up a CI/CD pipeline with Github actions or something similar. It takes maybe a day to set up test runners, and you can just sprinkle in small tests as you go. There are plenty of templates you can find depending on your language/platform that do most of this out of the box.
You don't need a perfect pipeline or test coverage, just something you can improve on incrementally. It's much, much harder to do all this on top of a bloated legacy codebase and infrastructure and that's when "adding CI/CD" becomes a Big Project that we'll get to real soon now.