How to reorganize the development process and increase its speed if there is no documentation, a bunch of crutches and old code?

Question

Agile

Hello!
5 years ago I created a project for which one remote developer and designer was hired. I acted as a PM.
During this time, the project has grown and expanded a lot and there was a need to increase the speed of development, more programmers are needed.
But of course, no documentation was kept, it is difficult to understand the code, the initial version has acquired a ton of features and crutches, the framework is outdated for a long time, the developer himself does not want to bother with refactoring / rewriting, introducing "best practice", etc.
The development speed is falling, crutches make themselves known know it all depends on one person.
I want to put everything in order: documentation, testing, versioning, CI, etc. beauty. But I don’t have such competencies and I don’t have the opportunity to explore the possibilities, I have money.
Need help. How to proceed?
PS current idea. Do at least some documentation on the project and look for a team leader with experience who will undertake to clean up the mess. Or, as an option, outsource completely, but the lack of flexibility / efficiency scares.

Answer 1

There is only one option. Look for normal developers, do NORMAL documentation, establish processes, automate everything that should be automated, refactor everything that should be refactored, throw out crutches and replace them with normal solutions. You can gradually, if possible, and not all at once.
You can outsource. This is a fairly common problem where the current team doesn't want to change, or is unable to change anything. We have a decent number of such projects. Outsourcing (you can also to another team inside) a more motivated team is one of the ways out.

Answer 2

The first thing you need to realize is that the project is in deep G. The cost and duration of getting out of there is significant. This means that it is most likely not possible to do everything beautifully at once. This means that you need to choose what is more important and do it first.
Determine the most significant risks for the project. From what is listed, for my taste, these are all eggs in one basket (one developer) and no testing. It is important to understand that the presence of crutches in itself is not as critical as some specialists sing. Much more critical is the lack of regression testing.
I would postpone the task of documenting to later stages, since it would be much easier and more efficient to put two developers for two weeks for pair coding and set the task of transferring knowledge from one head to another. Developers should be about the same level so that the strong one does not put pressure on the junior.
With the task of setting up CI, I would not be in a hurry either. If the execution time of one task takes a week, then accelerating the release of the assembly through CI by 1 day does not solve anything. CI is good when several developers make changes to their branches, when there are autotests, etc.
This implies the primary task - the development of autotests that will perform the most important functions:
1. fix the current requirements for the system, that is, answer the question of how it should work
2. insure against bugs that may occur due to crutches and inexperienced programmers
3. stabilize the development branches before merging into the master branch
To create autotests, you don't need a developer, you need a tester with skills in creating autotests. Only when there are autotests does it make sense to accelerate the development speed by attracting new programmers, doing CI and fixing technical solutions that are important for further development along the way.

Answer 3

In order not to repeat myself, I want to say one more thought that helped some projects.
Sometimes the number of "features" and crutches goes off scale, and technologies become so obsolete that the only adequate solution is to become a "phoenix".
Sometimes it is worth rewriting everything again using old developments and transferring the necessary functionality to a new environment. In this case, it becomes possible to start maintaining all the necessary types of documentation.
Of course, this method only works in a case like yours. those. when you have enough resources (time and finances) to hire professionals capable of such an action. By simplifying the current scheme as much as possible, transferring it to the new functionality and having at least the minimum necessary documentation, it will be easier for you to maintain and modify what you get in the end.
Of course, this is a VERY difficult and risky step, but sometimes doing it again is much easier than reanimating a dying one.