Maybe you should focus more on an outside-in architecture. You start with what the user wants and end doing what you need to achieve that. Otherwise, you might start with what you think the user wants and end up with an interface for controlling that, instead of an interface dedicated to the needs of the end-user. Having a well designed back-end is very important, but not as important as a well designed front-end, because the user will care that something isn't work properly, but he will care about it a lot less than he will care about the fact that the option isn't even there! You just teach the user that bugs will always be fixed and he'll be happy to know that the next iteration will include the option he wants. If he doesn't even see the option on the screen, he just can't imagine it and he will think that you don't care about his needs. Users need slick front-ends and they don't give a shit about OOP, layering and all the other "details" involved in the process of programming quality applications. Maybe the company which wanted to pay for that project knew this and they knew that there would be time and money to re-factor the back-end as soon as the users saw a shiny interface and started paying for what they got.
In other words: Computer programming is very difficult, but that (unfortunately) doesn't work as an excuse for not packaging your product properly. Packaging is the only indicator that the user has to judge if your product is well done or not, because regular people just don't give a shit about any kind of abstract notion such as "performance."
The only performance the user cares about is how much faster he will be able to do his work using your product.