> messy startup spaghetti code to something more stable and resilient? Maybe the first thing is to try to identify what the actual specific problems are. Solve

> messy startup spaghetti code to something more stable and resilient? Maybe the first thing is to try to identify what the actual specific problems are. Solve the key problems you actually have now, not the problems you want to have. This probably needs to be driven from a problem identified in the business then mapped across to what is happening in the tech stack / codebase / organisational processes. Messy code in itself isn't a problem. Symptoms of problems could be: our customers are leaving because we don't have enough uptime, every second time we make a release we break something but don't notice until our customers email us weeks later with a support request, there is a piece of business critical code that we need to change but everyone is too afraid of introducing bugs to change it, the former lead developer left and no one understands any of the code in subsystem xyz, releases are a huge scary manual process involving the whole company with a high failure rate. Each of these are different problems and will probably require different solutions Hopefully you're using version control, writing automated tests, have CI set up that blocks changes from being merged if they cause test failures, have mandatory code review from a peer as part of the standard development process, and have some kind of repeatability/traceability built in to deployment process so it is very easy to tell exactly what version of code was live at any given time. Monitoring for production systems is a pretty great idea too. Nygard's "release it!" book is a pretty good read with a mix of case studies/war stories and discussion of techniques that can be used to build systems that are able to cope better when failure occurs: https://pragprog.com/titles/mnee2/ https://pragprog.com/titles/mnee2/ I got quite a bit out of it as a programmer who had largely been writing application code in backend systems for a decade but didn't have much experience of building reliable services. A different kind of problem is to find yourself in a situation where there is a lot of complex business critical code that must be changed (new feature/bug fix) but the code has no automated test suite to give anyone confidence that the proposed changes will not introduce regressions. A rough rule of thumb is to first try to get an automated regression test suite wrapped around the code before changing the code, so you have a reliable indicator that can detect if you have accidentally changed the functional behaviour of the code. Depending on how the code is written exactly this can be very hard -- e.g. if the behaviour of the code depends on a lot of side effects it might take a few days or weeks of analysis and very paranoid surgical patches to modify the code enough so it is possible to get it to produce deterministic output from fixed inputs in a regression test harness. Once there are automated regression tests in place that can detect changes in functional behaviour it is much easier to perform "refactor to test" changes with speed and confidence, to restructure code so it is possible to decouple things so fine grained unit tests can be injected to test specific functional behaviour.