Programmer-Tester-Ratio

You do have testers. Only, you call them "end users." This is detrimental for all the reasons you describe; no matter how conscientious a coder you are, you're simply never going to be able to do a good enough job overcoming your own preconceptions about how the code is "supposed" to be used for you to find all the ways it can screw up.

You need to re-open this issue with management. By this point, it sounds like you have some hard data to back your case; the current hands-off approach to Quality Assurance both wastes your time and compromises your users' experience. You need to be careful in how you present this so that it's clear this is a structural problem and not a case of "You just suck at testing," but it sounds like a discussion that needs to happen.

It sounds like you're coming to a crossroads with this employer. If you're intent on remaining a programmer and nothing else, you may need to start pushing back and requesting that they start getting you the help you need to take some of the managerial tasks off your plate, either by bringing in somebody new or by expanding an existing co-worker's responsibilities. ("This isn't what you hired me for, and these tasks aren't going away. Time I spend doing this stuff badly is time I'm not spending on what I'm good at.") But that may or may not be realistic. Do you think you could handle moving into to a more managerial role if they gave you the resources and authority you'd need to get the job done right?

As to how big does a project need to be before it needs testers, I'm not sure how to precisely define that line, but I definitely think you've crossed it. You're spending more time than you'd like fixing bug reports coming in from actual users; to me that says it's time to spend more effort stopping the bugs from getting to the users in the first place.

The easiest way to improve communication is to work together with your developers (and designers and architects etc) and slowly breaking down those silly roles and eventually realize that we all are testers, except that some of us are have more experience than others.

For agile, just do it "by the book". Testers are part of the team and not just some external entity that you hand over stuff to when it's done. Your valued expertise is put to use during the whole development. First when creating user stories you help derive acceptance tests and make them automated. These tests are then used by the developers in their work. You also spend time daily to with exploratory testing of partial and completed work, and talk with the PO to clarify and improve your tests continuously.

That is what I mean when I talk about "work together". I am completely sure this is how communication in a team should work. This article explains it very well btw.

Opposite to this, many organizations like to handle development by putting all testers (and DBAs, and designers and programmers) in separate departments. This works against communication and only serves to cements the idea of phased development. Trying to improve communication in such a situation is possible, but the minor improvements you can expect is not worth the effort. At least not compared to actually putting people in the same room and creating cross-functional teams.