Writing research software that works efficiently on a parallel computer is a challenging task. Therefore, models are often developed as a sequential code with parallelization as an afterthought, which makes them very difficult to parallelize, or as a parallel code from the start, which makes them very complicated for the researchers that work on them. This is especially problematic since people that work with these codes generally only work with them for the duration of their project. If there is insufficient continuity between the projects, knowledge of how to use the codes or work on them may get lost, which renders the developed software useless. In climate modelling, this is a prominent issue, since the models are complex, are usually intercoupled with other models (e.g. ocean, atmosphere, ice), take a very long time to run (i.e. multiple months) and require large amounts of parallelism to reach a sufficient resolution (i.e. using thousands of cores for a single run). Therefore, ease of developing and using the parallel software is crucial. We developed two Python libraries, TransiFlow [2] for performing bifurcation analysis and studying transitions in three-dimensional flows, and JaDaPy [1] for computing generalized eigenvalues. In TransiFlow and JaDaPy, the main models and algorithms are fully agnostic of the backend that is used for performing the actual computations. To switch between different backends (currently SciPy, Trilinos, OMUSE and PETSc), the user has to change merely a single parameter during the initialization of their program. This allows the user to develop their model on their own machine (e.g. a laptop) in Python using the SciPy backend, and once the model works, run a large scale simulation on a supercomputer using e.g. the Trilinos backend, which can use a combination of OpenMP, MPI and potentially GPUs, without requiring any changes to the code. The computationally expensive parts of the program are implemented by these libraries, so we often do not have to worry about the efficiency of the Python implementation of the model. Initial tests show us that the overhead of using Python is less than 1% of the total computational cost. References [1] S. Baars and H. A. Dijkstra. JaDaPy. https://github.com/BIMAU/jadapy, 2023. [2] S. Baars, F. W. Wubs, and H. A. Dijkstra. TransiFlow. https://github.com/BIMAU/transiflow, 2023.