Nobody is suggesting we "do everything in the ideal way". We're suggesting taking 5 minutes to think about the thing you're writing in the next 30. It produces less buggy code, and likely, be able to complete the task with less iteration because you made the mistakes in your head and changed plans before you wrote them out.

I close out 30 tickets a week, other teams at our company are lucky if they close out that many as a team. I'm not trading quantity for quality at all, I'm simply choosing to do the things that matter and I ignore everything else.

And writing bug free/low bug code is about experience level and how your development methodology is -- not about spending more wall clock time. (I.e. for the quality you may spend more on salaries per hour, but not more hours -- probably a very good idea for a startup IMO)

I believe that in many situations high quality code is a LOWER net investment than low quality code.

This statement requires one caveat: your codebase sunset date.

Without it you can justify basically anything on the quality slider.

Code with bugs can just sink your team in the first months after hitting production..

Building something the right way usually means it runs better with much lower maintenance overhead and is easier to extend or replace later.