Mike, in his own words:
I went through the app, listed out the bugs I was finding for each
component, mocked up a couple small graphical changes, and sent them over to
the developer.
bugs are covered under a fixed price contract. Changes aren't. And Mike is a marketer / photographer; do you really believe he has any idea of the difference between a "small graphical change" and something that requires a code change? The developer is at fault only for agreeing to any changes without a price increase.And thus the classic problem with fixed price contracts: when I've done them I've been really clear with clients that no changes are included. Bugs yes, but every change is a renegotiation. Now often the lines between those two are a bit blurry, and I try to give clients the benefit of the doubt. But I bid to a very specific spec, and what can seem like a tiny change often goes against the grain of assumptions built into the code and is anything but tiny. To a person, clients agree then whine down the road when guess what, that change is a price increase. Sigh. The answer is to not do fixed price; it just sets you up in a very adversarial relationship with your client.
Plus, well, if you pay bottom price you get bottom quality.