"Right action, right time" Eric Ries
The key is to invest in the parts of the product that need that attention. In the early parts of a startup (MVP) then it's all about building something to put in front of users.
As that scales, then you can spend some time paying down the technical debt by getting good Unit Test coverage, and eventually building automated deployments and an integration server.
I would spend more time trying to get to some level of Product/Market fit first before spending too much time on development processes that might not matter if you fail to build anything someone wants.
You'll usually feel the impact of what's missing as users report more bugs, or the # of defects your dealing with weekly outweight the # of features.
Right time, right action. Start simple.
(If you want something more concrete, just do 80/20 - 80% on user facing / value creating stories, 20% of paying down code debt / automation).
Fast to market, end of story.
I built and sold a company that's now doing $XX millions/year in code review tools specifically, so if anyone should push for code reviews and other "proper" development practices, it's me. :-)
But you shouldn't at first. Ship things that delight people. Change the product to match what people really need. Let function and form follow pain and need and checkbooks.
You will accumulate technical debt. GOOD. That means you're spending time derisking the business, which is your primary job always, but never more so than at the start.
You will have to pay that down later. So your goal is to get the business to the point where it's doing so well, that tech debt is actually hindering you AND you have some resources to devote to it.
Good problem to have. Most companies never get to the point of having the problem. That's the point!
Product should be light, simple, focused, constrained & fast. Remove the biggest pain of the identified customer problem and have the solution, visual identity and everything else demonstrate that's what you're doing. Resonate in a way that has the customers you're building for recognize themselves, their problem and the solution in all you do and how you do it.
Said another way, if it doesn't have a meaningful impact on solving the customer problem in a resonant way, in the early days it's just a distraction.
Cost/benefit.
What part of the code do you need to test? We only test stable, consumer facing features. Those are the places where errors are costly (upset customers not coming back). Don't care so much for internal facing, or experiments, where we have higher tolerance for failure.
Some code is fundamental, good quality means faster iterations, so we refactor early and often. Most code has little dependency and worn change, so we leave it at that.
Code reviews are great way to increase quality and share learning, but again you can get both by only reviewing some of it (probably the same tested and refactored portions).
It all boils down to understanding that tests, refactoring, and code reviews have business value, and that value varies by code responsibility. So focus on areas that matter.
