Every working application got to where it is by making technical decisions. So from one perspective, those decisions are in the past and there's nothing to talk

Every working application got to where it is by making technical decisions. So from one perspective, those decisions are in the past and there's nothing to talk about. You might need to accept that you can't re-litigate those decisions without a time machine. It helps to be very honest about the current state of the application and take specific note of why things were done that way; ie "Chesterton's Fence". Even if the reason is "because I felt like it", the decisions should be retrospectively documented. Next you want to present an informal vision of the way it COULD be. In your case, you'd want to paint a picture of daily life in a monolith, and contrast that to your current system. Do not push strongly for your solution at this point; keep it conversational, "what ifs". Now comes the hard part, getting from here to there. Burning it down and starting from scratch is rarely an option. You need to propose a series of refactors (linear, since you're 1 developer) that will eventually get you to the final place. But the trick is, the changes can't break the existing app and changes need to be incremental and self-contained such that you can stop and work on features, bugs, etc. Focus on the high-priority stuff first, realizing that you may never fully get there. Finally, there's a real chance that the boss will say "No thanks, this doesn't add value". Then it's your job to start documenting technical debt interest payments. In your case, this should be pretty easy - any time you have to deal with a data inconsistency or a race condition, it's 100% interest since there are known solutions - your boss chooses not to use them but he should at least be made aware of the cost and drag this puts on velocity.