I think the quote that comes to mind for me (as someone who's been with 2 startups now that have grown from less than 20 employees to more than 300) is this:
One man's trash is another man's treasure.
"Good" code written with the constraints of a tiny company won't be "good" code later anyways - the requirements will shift, the company goals will change, focus will change away from some features towards other features, abstraction levels will be different, the quality of your engineers will be different.
Trying to bake in assumptions about what "good" will be 5 years down the line is literally pain for no reason, and I promise you it will be wrong anyways.
Trying to act like the company from 5 years down the line is a guaranteed way to go out of business in the mean time.
In my opinion, investing early on in CI/CD pays so much more than thinking about code quality, correct abstractions and future requirements. If I have a fast deployment strategy with automated testing I can trust, accommodating new features is a breeze regardless of the underlying code quality.
Of course though it's all a balancing act. I could spend a year building a solution using sophisticated tools like spinnaker, only to completely miss the market at a startup. Still, if there is a tradeoff to be made between code quality and CI/CD, I'd always side with CI/CD.
So before fixing other things you need to be able to build it.