Strictly from a scrum perspective, it sounds like what you're doing wrong is that you're not working _with_ the client. You need to work together with the client to come to an understanding of what they _need_ and not just what they _want_. Do they need a series of quick fixes, or do they need a stable, maintainable system that will serve them in the long term? That can be hard to determine, but quality is as much of a requirement as a background color or performance benchmark. The customer needs to be aware that stability and maintainability aren't free, and has to be engineered into the product. 

If they say it is the former, you are doing nothing wrong -- assuming you're explaining to them in the sprint reviews that you're cutting engineering corners to meet their goals. 

If they say it is the latter, then what you're doing wrong is that you're not giving them what they want.

One of the cornerstones of Scrum is transparency. If you're doing scrum, you should be doing sprint reviews with the customer. In those reviews, are you telling the customer that you're cutting corners in order to deliver software faster? If not, you should be. You need to be 100% clear with your customer about the ramifications of your design choices, to give them a chance to make an informed decision as to whether you are delivering your software with an appropriate level of quality.