Take a few steps back and relax. If you were looking at this from the Space Station, who would you say has a problem with the code base? That's right, your client. Not you. Your client.

If he/she has 150 installs and 150 angry clients he/she knows that this thing is rotten somewhere. You client may or may not have some technical understanding but rest assured that they understand business.

Life often boils down to binary decision. You have two choices. Gracefully exit and move on or try to help your client.

If you choose option B you've also made another choice: Your first job is NOT to be a programmer. No, you are going to have to be a teacher.

You have to do your best to explain to your client why he might be sitting on a ticking time bomb (or whatever you might want to call it). It is imperative that your client understand that he has handed you an ugly, stinking, putrid and smelly mess. Without client buy-in I would walk away.

Now, here's the challenge: You have to find a way to communicate the problem that is not menacingly full of CS jargon and acronyms that mean exactly zero to your client.

I've had to deal with these kinds of problems before. On one or two occasions I made the mistake of not securing an understanding with my client and suffered the consequences. These were miserable walking-through-feces-infested-mud experiences. Never again. Once I learned that lesson things changed. My most memorable experience was when I got client buy-in from a major international corporation and, once they realized that they had a huge problem, they put me up at the Waldorf Astoria in Manhattan for a full month (these guys are so big that they have rooms pre-paid for "emergencies"). Imagine a guy in a t-shirt, jeans and sandals showing up at the Astoria. I've never been looked at like that before. Once they realized who my employer was things changed. Fuck, the room had marble and gold-plated crap everywhere.

But I digress, the point of that last example is that once a client understand the degree of the problem in their hands things change. If having a solution to this problem is important enough there is no end to what they will spend to fix it. Is it a business-killing problem? Even better.

Judging from your description my proposal to your client --after they really, really get it-- is to re-write their entire app from scratch.

I would further propose that you are going to need to hire a few more people (two to five?) in order to get this done as quickly as possible. And, yes, this will be expensive.

You can use many analogies to explain the problem. I'll leave that up to you. I've used ideas like that of constructing a building on a foundation of sand rather than concrete while using substandard supplies rather than industry-accepted good quality building components. Whatever analogy you use, it has to convey the severity of the problem without resorting to CS. If your client has some technical chops you can get into it a little AFTER you are done with your analogy.

Finally, the most important part: You have to be willing to walk away from it. You state the problem and explain that it will be expensive. You also state that you are not interested in anything other than a full re-write of the app because you are not in the business of doing further damage to your clients. Respectfully suggest that without full buy-in you'll need to move on and he will need to find another developer who might we willing to patch this thing up.

In many ways, it's that simple. Two choices.