Here's my thoughts on the subject: Development time is not calculated by how much code you have to write but rather by how fragile or error-prone writing that code is.
You have to take a look at the trade-offs that statically typed languages have for your code, your team and how things are communicated. It's important to question yourself and the team on:
A lot of these questions can be largely solved by having type information at your disposal.
Code patterns does not solve these problems. Why? Because we are human and humans make mistakes. All the time, by nature. It does not matter how secure and restrictive your environment is, there will always be a chance of failure.
But the question is what types of failure this is, and how easy they are to avoid either before they happen, but also how that can be remedied after they happen. Some failures are more destructive than others and you have to consider the pros and cons, depending on the type of product that you make.
Statically typed languages can help you avoid undefined behaviour in most common cases. Since you consume the contracts that types and interfaces gives you, it is almost impossible to fall into a rabbit hole of passing wrong data types around and cause unexpected problems that can be hard and tedious to debug.
Statically typed languages provides ways to define contracts, that can be passed around in a program to ensure that at any point where the data flows, you can ensure that integrity of how that data can be consumed.
This also has the benefit of being extremly easy to use an API, without having to consult to external sources or documentations. With types, you don't need to inspect implementation details since the input and output is documented and available upon usage with intellisense and code completion.
However, in a project that is purely TypeScript and not meant to be consumed by a public audience, these guards only adds more weight.
TypeScript uses inference to guess the types of values that you pass around. In 95% of cases, it works really well and you won't need to define type information, given that your code is written in a way that the inference can understand and follow.
This can help you write better code, too, that is deterministic, since that is how inference work.
Of course you can always get around it by forcing your code style, but that comes at a cost that you have to manage the type information yourself, for example by casting or provide types to declarations.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.