The first thing that needs to be strangled is unachievable management promises. Figure out how to get local management to not write checks the tiny team can't cash. A team of 3 juniors will likely overestimate their ability to deliver, so you've probably got to teach them to say no to things they can't do also.
https://medium.com/@kris-nova/organic-and-mechanistic-system...
What you are dealing with is organically grown software. No one really understands it, and it's likely to be fragile.
I agree with all those here that say the first thing to do is to introduce version control. You don't want to break that money machine without a way to revert.
Second, introduce some lightweight form of code review, but don't tick people off.
Third, if you want to do something like revise the user interface, consider adding an API to the existing organic code base, and build the new UI with that API. Generally, take that approach and avoid jamming something into the middle of the existing code that no one fully understands.
The thing I'd suggest taking a look at is the database. You really need to make sure the new part is not based on the old data model.
You can take a look at "getting started with DDD when surrounded by legacy systems" by Eric Evans - available for free and only 21 pages long. Our implementation of one of the suggested approaches failed in one project, but in retrospective, I think it was caused by the business not putting enough effort into the rewrite.
In general, on the high level it's very important to make the product vision, data model, processes clear and well thought. Without this, you will always get to a bad codebase within a couple of years.
"u" is next to "i" on many keyboards.