I suggest that your client's apparent anger is nothing more than a negotiation tactic - whether they are consciously aware of this or not.

If you have agreed a list of requirements and a price, and you have this written down and signed off by both parties, then you should stick to your guns. Giving in to your client's demands will most likely lead to them asking for more and more things not in the original list. They will simply stomp all over you.

When I worked freelance I included a clause that said something along the lines of: "Any additional work required that is not included in this document will be quoted for on a new project basis."

I made sure I charged at quite a higher rate than I had done for the original quote, due to the extra effort involved in ensuring that the new request(s) didn't break functionality elsewhere or result in me having to refactor significant portions of code.

This is sort of what happened when they asked for the new features, we responded with estimates for that work and explained why it wasn't included ... they got pretty upset. Implied WE were the ones playing a game or something, when of course, from our end this is just totally straightforward.

It is called managing expectations, and it requires communication, communication, communication.

You may have the contract on your side, but in the end, building a successful freelance practice depends heavily on repeat business, so it is up to you, the expert on the subject, to bring this issues up early enough and make sure they actually understand what you are talking about.

(I feel your pain)

This is a terribly common refrain. Perhaps all freelance developers in a given area should collaborate (read: collude) and come up with an agreed upon, open source scope of work document framework? That way, setting aside variables like price, feature requests, and time estimates, there can at least be a common structure that developers in a particular geography can rally around to at least attempt to minimize the impact of this type of problem.

This is the precise reason why I am trying my best to come up with my next start up idea, client work is a drain...

You could increase your price or you could agree to get what was originally planned done first and then look at the new extra stuff.

Well, the problem is that they insist on neither: that both the price stay the same and that the extra stuff is required. Rock - Me - Hard place.

BUT I do feel bad in these cases because I believe they thought it would be included. Plus it may truly be necessary for the final product to be useful for them. So I want to help them, plus, ya know, don't want them pissed at me :)

Personally, I'd say you just apologise for misunderstanding their intentions, politely inform them that the new feature is going to cost extra, and then suggest that, due to the misunderstanding, you're going to reduce your price for that implementation to $X, where $X is either the price you actually have in mind (if you don't mind being less than 100% truthful for the sake of fairness) or a slightly lower price (if you're willing to pay for their mistake so as to maintain more truthfulness). Yes, it can be hard to admit to mistakes you didn't actually make, but it's often necessary to not piss off some people.

i would try to cut scope on other items or at least compare the value of this item to other items. To do this you need a deep understanding of the core value of the app and how each feature contributes to the value.

Ultimately tell him your bid is based on hours and you are fine to switch things around.

It depends on what the new stuff involves. If it's details on already-decided features, just tell them "well that's going to take some more hours than already estimated," and if it's for things that are out of scope (design is a common one), just say, "that'll be extra." Have a sense of the scope and don't be afraid to tell them that will cost more. You should be able to explain the scope as you understand it and why the request falls outside of it. If you treat the agreed-spec like a checklist, it makes it much easier to clarify the amount of work you'll be doing.

You should reply to the clients when you provide the original quote with a very succinct summary/bullet list of what is being provided - SUPER SUCCINCT. and get them to sing-off on that

So if they come back with anything, and it is not boiled down into the bullet item list of features - its additional service request.

This might help them to further think about their product.

One thing that always pisses me off when getting a quote from a developer is when they say some large number of hours are required for some nebulous task.

"Setup development environment: 40 hours"

or something similar.

shouldn't your development environment be setup? or streamlined such to not require 40 hours?

so, make sure you reply to them with a super succinct understanding of what is to be delivered and this will be the go-to document for any discussion about scope.

This is good advice, and I think that's what went wrong in this case. We were told to estimate based on what we had, even though we needed to go deeper. The rationale was that we couldn't put so much time into a proposal that was so small. And on a smaller project, more risk was acceptable, which is okay, I guess, but then this is what happens.

"Setup development environment: 40 hours"

This is ridiculous, though, well UNLESS you are hiring someone to pick up work on a large existing project, in which case they may actually need the time to get all the dependencies and get it running. To be clear, our items are always in chunks of actual functionality, because this makes the most sense to ... well, everyone. And it makes it easier for them to pick and choose/set priorities/etc.

EDIT;

You also need to make sure you inlcude a statment of what the quote/project IS NOT.

They need to sign off on this too.

So that when they ask for something, and if it is describe in what the work is NOT, then there will be no confusion about what IS included.

You should take a class in project management.

Seriously. It will help a lot with this type of situation.