Don't give ranges! Let's say a prospect asks me "how much to do this Release?" I could say - "Somewhere between $15k - $20k". I hear 20, the prospect hears 15. I'm pleased we got it done for $25k with a whole bunch of changes, the client is annoyed we didn't get it done in 12. So I never give a range to a client. I tell them that the first Release, along with its spec is likely to take $35k. That's two guys working full time for two weeks.
Be upfront about bugs I don't believe there is such a thing as bugless software. It's important to admit that bugs will happen. Bugs will get through testing, and bugs will cause a headache in production. In a fixed price agreement we cover bugs, because the goal posts are stuck in the ground, but in hourly-rate work, bugs are covered by the client. See what is covered in fixed price contracts for more information in relation to what is and what is not a bug.
Fixed prices don't solve anything: A big fixed-price contract can also be dangerous in managing expectations because it removes flexibility. If you deliver exactly what the spec says, the client can quite easily be unhappy, because the hundred and one things they thought of during development weren't included. I recommend fixed-prices in Releases of no more than 3 weeks (1 - 2 releases) development which helps alleviate this problem. It will often occur that in the middle of a fixed price contract a client will ask you to add extra functionality. You should not do any such items straight away, but turn this request into a task for future development. You should generate another release plan for all the extra items once the fixed price contract has been signed off. It is important that the customer is always clear on what is part of a fixed price contract and what is not, that is why you should always finish a fixed price contract and have it signed off before starting extra work.
Talk dollars at the first meeting: Talking dollars with the client is often something consultants don't like doing after the initial meeting. I've heard of consultants refraining from sending invoices when a project is suffering a few delays, or the client is unhappy with the application state. What makes this consultant think that if the client is unhappy to receive an invoice now, they'll be happy to receive it in two months? We send invoices for time and material projects every week. This way the client is informed of costs every week, and if a hassle arises, it's trapped straight away.