When working on older codebases most developers encounter the question of “Should we fix this or rewrite it completely?”. Weeklong releases, multi-day bug hunts and a very obvious impact of tech debt on developer happiness and development velocity led us to ask that question in a very general way. We were wondering how a better approach to a Python-based infrastructure could look when working in a multi-disciplinary startup environment. We believe that many developers have been in a similar situation and we would like to introduce our holistic take on a when and how to refactor older codebases. Our solution to these problems consists of two main changes: moving the entire code of various teams in a uv-based monorepo and questioning a lot of technical decisions of the past under the paradigm of “Can this be done simpler or can we rephrase the problem to solve it with an existing technical solution?”. We will share our insights into how a multi-language monorepo approach can work at a startup where full-stack and ML practitioners work on the same code base. This includes going over standardized procedures (e.g. code quality) that are shared between all teams. Furthermore we will discuss some of the high-level decisions and introduce our reasoning within the available options of the python ecosystem. This includes for example why for us a monolithic approach based on Django works better than a Flask based microservice solution. The goal of this talk is to give the listener an introduction to our solutions and make it easy to draw parallels to their own situation or problems. Attendees will leave with an insight into our decision framework and we will show what metrics we used to validate the success of our refactoring and technical choices. A simple list of metrics and a dashboard will be open-sourced as part of this talk to give interested listeners a starting point with their own “refactoring” journey.