The issue with all of these things is that in a startup you don't know what the expected behavior is. You only can find that out, for sure, by putting it in front of customers and having them pay you for it - which often requires building the product or at least some approximation of it first, and may need to be repeated dozens to hundreds of times before you find something that is a.) useful b.) worth paying for c.) can't be found cheaper elsewhere and d.) has a large enough market to be worth building. You can and should short-circuit some of this with non-code development (eg. talking to customers, putting mockups in front of them, getting sign-ups on a landing page, signing LOIs), but you never know for sure that your product is worth it until people give you money in exchange for using the product.

Unit/acceptance/integration tests, if done right, capture requirements. They verify that the code does what it should do, and continues doing it even when changed. You can't write meaningful tests until you have some basic idea what the code should do - what would your expected results even be?

Logging, if done right, is about being able to quickly answer questions about the operation of your system. You learn which questions to ask only through the experience of having people actually use it. Logging can easily tell you fine-grained details about how much wall-clock each phase of your program takes. Should it? Well, depends - if you're about to rip all the code out and rewrite it, or if it's just something that runs once to generate some data and never again, it doesn't matter if it's slow.

Similarly, good logging can tell you precise details about how people are using the product. Should it? Here's a counterintuitive lesson learned the hard way: not until after you've answered the question of are people using the product. If you're getting a bounce rate of 100% (which you can determine by slapping Google Analytics on the front page), you need a completely different product concept, and it's a waste of time to instrument each user action with fine-grained logs until people are actually using it. You can always go back and add the logging then.

A motorbike is a poor analogy. The consequences of failure for most tech startups are significantly less than the consequence of a motorbike crash, the software is a lot easier to change than motorbike parts, and the goal of what the software does is a lot more ambiguous than what a motorbike should do. Rather, I'd use the analogy of a novel. Your first draft of a novel is going to suck, it'll barely make sense, and the goal is just to get your thoughts down on paper. When you do revise it, you revise for plot & character first, then pacing and voice and realism and sensitivity, then you might clean up dialogue & wording, and only then do you look for typos. Why? Because there's no point in fixing typos for passages that are going to get ripped out and replaced anyway. Spelling and grammar is the part that everybody thinks of because it's the part everybody can do, but it's really the last part of putting together a finished story.

Similarly, unit tests & CI & logging & one-click builds are the parts that everybody thinks of when they hear "development" because they're the parts that everybody should be able to do, but they're the last phase of building a worthwhile product. The first questions are "Who is using this? What are they trying to accomplish? How does it deliver value? How is it different from other alternatives available?"

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.