It depends. If I would have at least one other developer excited about more advanced static types, I would try to sell to the project lead something along the

It depends. If I would have at least one other developer excited about more advanced static types, I would try to sell to the project lead something along the lines "Hey, me and $OTHER_DEV would like to take $SMALL_PART_OF_THE_APPLICATION and try to rewrite it in $LANGUAGE_OF_YOUR_CHOICE ... we think the type-system should catch quite a lot of those bugs we have been dealing in prod!" If the lead will take you up on that, you might have a nice way to introduce the language and figure out if it really is that much better. If that is not an option (i.e. no easily identifiable sub-component/service) you still might be able to add types through mypy, and maybe even investigate something like mokeytype If there is really strong pushback to do static-type checking, you can still make mission critical systems in untyped language. Erlang does this, and you can take the lessons learned from i.e. erlang and apply it in your python code-base. Based on my experience, limitting local state, and use more functional approach does wonders to testability and stability. If the team is not a fan of functional programming, Maybe even throw in some advanced testing techniques, like fuzzing endpoints, doing property-based tedts or if it is applicable something like chaos-monkey :) If there is no time for that, then focus on the process. Good review culture, good test-writing culture, have CI and integration tests ... To be honest, I would try all of these, starting from the last suggestion, making my way to the first :D [1] https://github.com/Instagram/MonkeyType https://github.com/Instagram/MonkeyType