How to approach the ol' “this will just be a small application”? Yeah right?

Question

Ok I have run into this many times, but here is the worse case scenario slightly exaggerated.

A client says "hey can you make us this small module to do this small task"?
Me: "Sure no problem".

So based on budgets and constraints etc., I skip some of the architecting and dive right in and make it no sweat.

Then they ask for another module. And another. And some enhancements. And this all happens very slowly mind you, over years. And before you know it, you have this monster application that is horribly architected.

What do you do when you are asked to do something small? You don't know if it will keep growing...if the client will keep asking for additions (and neither do they).

You can't over-architect the thing, because it's just a small application after all, and they will go somewhere else if you say (in that I know all voice) "Well just in case, let's architect this thing into layers with top-o-the-line security and separation of concerns. In fact let's go with a dependency injection tool that will really make this thing fantastic blah blah blah".

They will say "yeah right" and go to someone else.

Budget, time, and perception are as important as architecting the application itself.

How should this be approached?

I guess the question really boils down to "When you don't have all the information for the final outcome of what appears to be a small application, how do you avoid (or mitigate) making architecural and design decisions early on that will be completely innapropriate later?