Tradeoff Between Types and Devspeed

It seems as if there is always a trade-off between predictability with types when writing code and the speed at which this code can be written. I'm writing about programming languages, as developer tools.

Think about Rust, OCaml, even typed-Python. One is easier to implement and one is more robust to bugs. You don't want to launch a software 100% free of bugs after it has become obsolete. At the same time, you also don't want to launch a software so premature that it is as reliable as the flip of a coin.

There are two kinds of software here that change which side of the trade-off you would rather be on:

• The fresh new startup kind: you want to be the first to market. It's probably okay if you have a few bugs on the edge cases, but the fear of becoming obsolete before delivery is stronger. You can also improve the product from its users after the launch. You should be more afraid of not having any users by the time you launch.
• The incremental featureset kind: you're building a new component to a software that already exists and has users. You won't lose all your revenue if you are late by a few weeks. You will, however, lose revenue if your new commit causes the website to crash for some paying customers.

My hypothesis is that when starting out, you want to build for speed. Once built, you want to focus on making it better. An approach that gives you bug-free software from the ground up will take more time from the beginning. Instead, the ideal approach would let you start loose and then make your software more and more robust as your company matures. No programming language factors this into its construction. Most companies will just rewrite at some point.

I guess you want the best of both worlds and the ability to move slowly from one edge to the other. I'm starting to appreciate Python for this.