Sprints - How few is too few?

I believe firmly that there are a minimum number of Sprints necessary for Agile to work

That's right, any less than 4 Sprints and you won't get the Customer feedback you need.  Think about this:

• Sprint 1 Review: Typically this is a barebones presentation.  The product (website etc.) doesn't look like much yet, and the Customer generally says, "Great - glad to know we're progressing." 
• Sprint 2 Review: Okay, now there's something to see and the feedback starts coming in.
• Sprint 3 Review: More to see = more feedback. 
• Sprint 4 Review: You're done.  UAT ("hardening") may follow and will produce feedback, but it should be tweaking the product, not continuing to design it.

So that's 2 touchpoints for the Customer.  That is barely useful - you run the risk of the Customer saying at the end of Sprint 3: "Wait a minute!  You're telling me that we only have 1 Sprint left and it's almost full already? - I barely got to provide any input!  This product isn't even close to being ready."
You are now in a sticky situation.
Even with 4 Sprints.
So what do you do if the project won't sustain 4 or more Sprints?

1. Reduce the Sprint duration.  E.g. from 2 weeks to 1 week.  That will allow you to double the number of Sprints without affecting budget or schedule.
2. Don't use Sprints.  The project may be short enough that you can do all of the design up front and just have a single development/test cycle.  In other words, don't use Scrum.

Note that I didn't say, "Don't use Agile."  You could still use a Backlog, a Task Board, a Burndown chart etc - in fact, we typically do in these situations.  In fact, you could shift to Kanban. 

Have you had to deal with adapting Agile to smaller projects like this?  How have you handled it?