You say in one of the comments that this is your first job. Managers often aren't technical anywhere except a dedicated software shop in my experience. This is part of life, just get used to that.
You cry and whine because there is no one to appreciate the elegance of your solutions. The real problem here isn't that there is no one to appreciate the elegance of your solutions, but that there is no one to teach you that your solutions aren't nearly as good as you think they are. Virtually all new programmers overestimate their actual skills. With no mentor, there is no one to help you to better practices. If there is no one there to mentor you, then join local user groups, actively participate, and get someone there to mentor you. Even better, that will help you find a better job eventually.
You score a zero on the Joel test? If you are the only coder (and it sounds from what you wrote that you are) they why aren't you using source control? What is preventing you? If you aren't the only coder, why is there no one who can do code reviews? All our devs do code review, it isn't a management function especially when the managers are non-technical.
Requirements change in pretty much all places. Business needs change continually and non-programmers often can't visualize what the program will do until they ee something. Then they realize it isn't what they need. That's why Agile came into being really because the older methods were not handling that change well.
Set up bug tracking even if the management doesn't want to enter the data themselves. Be responsible for entering new bug/features as someone mentions them to you. It really helps to be able to tell the manager when he wants a change that you have been assigned 27 other things and here is the list, which one do you want me to move down the priority list to accomodate this new change. It will help at review time because you will be able to count up the number of bug fixes and features you implemented. If everyone isn't using it, then at least you can for your own work. If they won't let you install any software then use an Excel spreadsheet. Take some initiative. Once you can show results, others will be more interested. If you think there is too much work for one person, the bug tracker will help you prove it.
Do not provde polished looking demos! Demos should look as if they are scribbled in pen on a piece of paper. The more polished the interface looks the more the non-technical person thinks it is finished.
Even though no one would know if you don't follow best practices and semi_hard code for instance, you will know and you will get into sloppy, bad habits. That will not serve you well in your next job. So do things as close to the right way that you possibly can under the circumstances. Make sure to write tests (just consider this as part of the development time and put the time to do it in any estimates you give managment even if you don't specifically say that is part of the estimate) and use those test to makes sure later changes don't break something else.
You need to view this as a priceless opportunity to grow and improve. You have more freedom in the actual coding than many people have at that stage of your career. So consider this an opportunity to create a portfolio of successful implemented projects. When you do go looking for that next job, being able to point out such accomplishments as institutited source control, instituted bug tracking, created X number of successful project implementations, etc, will make you stand out from the rest.
You also have a great opportunity here to learn how to manage expectations upward. This is askill that will come in handy the rest of your career. You have nothing to lose in trying to do this here, things are already not good. But you can learn the political skills that will help you in better places later. Learn to do a cost-benefit analysis. Learn to undersatnd the business domain so that you can be convincing when you talk to them. Learn to talk in terms of benfits to the company and profit. Do estimations for every task you are assigned and even if they don't match waht management is giving you, keep records of what you estimated and what it actually took to improve your own ability to estimate work. Once you can show that your estimates historically have been more accurate than managment's, they will be more likely to listen when you tell them the estimate is too low. But you have to build a track record first of both more acfcurate estimates and most importantly, ability to deliver the projects and make them work. Again this is a good skill to have as you move up in your career.
Above all don't be passive and expect improvement to come from above.