Doing everything by the book, or according to the guidelines some random person published on Medium last Wednesday is a luxury we don't all have.
You have the merit of having done all that, and it works.
Now, sure, don't we all, to some extent, want to change everything when we arrive in a new environment? IMO, it comes down to a couple of things:
- Who make the choices of refactoring an app or not?
- What's the company roadmap.
To avoid being showed the door, I would advise you to support refactoring. Show enthusiasm and support. You could be the guy with the knowledge on how everything has been done and why, and that is greatly valued if the decision to refactor some app is made.
Eventually, the decision to do so will depend on time and money.
You should discuss the code base with your contact and let them know the scenario. Also, if you don't tell them I doubt they'll fire you for you are the resident expert. If they let you go, they'll basically be just be status quo for a long time while the new hires fix the working "mess" and figure out how to tie in 2 new apps. If these new recruits are for you to supervise, all the better. You'll be able to refactor the code faster and they will become very familiar with the system. Good luck!
I've been the incoming dev on a project like this. The CTO (a brilliant architecture guy who hadn't written code in a long time) built a proof of concept in a spaghetti of c# and PHP (drupal). It was an absolute mess, but it worked. It was actually impressive that he was able to build it all solo, and obviously with a team and infinite time he could have made the code pretty.
You have accomplished the same thing, which is building and shipping a whole app, which some of these incoming devs have not. Your job now can be to guide these devs in refactoring the individual pieces of the app while you keep an eye on the bigger picture. Think of a conductor in an orchestra...he can't play every instrument perfectly, but he can guide the individual musicians.