Well, there's two sides to that coin. By having the client pay hourly you put the "risk" of the project on his shoulders, but you also limit yourself to earning only a hourly rate. Why is that bad? An experienced programmer might accomplish a task/project quickly due to having done similar projects and have an arsenal of code/examples/tools at his disposal. An experienced programmer might be able to get 20%-30% markup on his hourly fee but he might finish the project five times as fast as another less experienced programmer might.

You won't be able to leverage your gray hairs and the time they save you as efficiently with an hourly fee.

If the project is well-defined you might be tempted to accept a fixed price and crank it out quickly which will net you more money per hour. I'd advice holding of atleast a week even if you do it in a day or two or the customer will start questioning your price ;)

If the project/customer is fast and loose with the spec and functionality (as most projects are) you're in dangerous terroritory where constant changes keeps eating away at your time.

If you can get a high hourly fee and the project is fuzzy, go for it, meetings and stuff like that will earn you a bunch anyways.

Another strategy is to split the project into discrete parts and charge a fixed price for each (negotiating each one), that way it's easier to define the scope of the project and it eliminates risk both ways. It also gives you and the customer have a chance to get to know each other before committing to the project and helps avoid being in the clutches of a psychopath customer.