As a freelance developer, I worked for two months for a client (company) building a software.

I drew up a quote mentioning 4 features: A, B, C et D. This quote was signed by the client.

At delivery time (happening now), the client criticises the lack of features E, F, and G.

On the one hand, it appears that the architecture of the software I built would allow to integrate E, F and G easily within a few hours of coding.

On the other hand, I expect them to be professional and be aware that they totally misread my quote.

How should I react as a professional?

  • Integrating E, F and G and deliver them without charging the client more to avoid potential conflic.
  • Refusing to integrate E,F and G unless I charge them more.


As @Falco pointed out in his comment below, I would add that I explicitly asked the client to test the solution as the product evolves (according to Agile practice) and it didn’t.

  • 91
    "Give them free work to keep the client" is an understandable but realistically awful idea. It sets the precedent of "if we complain, he'll do it at no charge." Even letting a client haggle on your time spent is bad; this is worse.
    – kungphu
    Commented Nov 7, 2016 at 9:12
  • 19
    "A few hours of coding" - what about testing, deployment, etc.?
    – Brandin
    Commented Nov 7, 2016 at 10:38
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Nov 10, 2016 at 23:44
  • Two thoughts not worthy of a full answer: (1) Ask them: "Why did you expected that E, F, & G would be included?" (2) Joel Spolsky gives a (somewhat) humorous account of this common phenomenon: “We built it exactly the way they wanted. The contract specified the whole thing down to the smallest detail. We delivered exactly what the contract said. But when we delivered it, they were crestfallen.” His advice: Get used to it. Customers don't know what they want. Even when they do, they don't have the skills to express it. (joelonsoftware.com/2002/02/13/the-iceberg-secret-revealed) Commented Feb 16, 2017 at 18:08

8 Answers 8


This is simple, get payment on what was contracted before doing any more. If they want EFGHIJKL then give them a quote on it. This is the professional way to do things.

If you do EFG before getting paid out of some misplaced sense of 'whatever', expect to be told to do HIJKLMNOPQRSTUVWXYZ.

Do what's in the contract, get paid, then negotiate anything extra.

I have been in this situation many times. I don't get into a prolonged dialogue about it, I just demand payment politely and professionally, keeping it short and clear. After that I ignore anything that doesn't include a confirmation of payment.

"All that is outside the scope of the work I originally quoted on and completed. I'm happy to negotiate doing it but I'll need to be paid for the existing work first. Please find enclosed a copy of my invoice and arrange payment as soon as you can so that we can move forwards. Kind regards etc,."

I have been told that this will lose me future work, but pragmatically it rarely has, secondly I don't have a use for a non-paying problematic client. Freelancers often put up with a lot for the money, but if the money isn't paid in a timely fashion there is no point.

Always remember that as a freelancer you are not in their hierarchy, any pandering to this sort of rubbish weakens your current and future negotiating position. Just entering into a involved dialogue over it costs you time and money and should be avoided.

  • 124
    "I have been told that this will lose me future work" - I suppose by clients who didn't want to pay up.
    – gnasher729
    Commented Nov 6, 2016 at 22:29
  • 38
    They've hinted as much as have my own people at times who are impressed by a companies size etc,., in practice I'm aware that it's a negotiating tactic and almost invariably not only kept the client and gotten more work, but put my price up on them. It doesn't matter how big and successful a client is, all that matters is how much money they put in my pocket.
    – Kilisi
    Commented Nov 6, 2016 at 22:33
  • 8
    FYPMA - where PMA stands for "Pay Me Applies". Many suppliers now actively shift the onus for gaps in requirements onto the client for exactly this reason. So then it is not our fault for failing to document requirements, it's their fault for not including them in their "stories".... Statement of work, scope statement. The work "meets requirements" and "functions as expected". Anything else is scope creep and can be triaged in UAT, and there should be a UAT, with the "real" users, not their agents or stand-in stakeholders.
    – mckenzm
    Commented Nov 7, 2016 at 4:01
  • 14
    The fun part is this rarely works for the client anyway. When we realized some of our clients were like this, we simply upped all the prices - the client got their fun out of haggling, got a good feeling of swindling us out of our money, and we got just as much money as when working with a reliable client. The craziest situations are where there are intermediaries that somehow convinced their clients they can negotiate things like this - in that case, the client feels they saved a lot of money thanks to the intermediary, while they actually lost quite a bit.
    – Luaan
    Commented Nov 7, 2016 at 12:02
  • 11
    @Luaan Charging a "premium" simply because a client repeatedly tries to scam you out of paying for the value of your time and effort is one of the more satisfying aspects of contracted work. Commented Nov 8, 2016 at 1:15

I have been a freelance developer for 30+ years. This is a situation I encountered on a number of occasions. However, most of the time it is not that hard to prevent or mitigate.

First, make sure that your quote is thorough and unambiguously worded.

Second, think of your customer as a partner; keep them informed during the development process; show them what you can, e.g., user interface mock-ups, so early on, they understand exactly what they will receive from you.

Third, in your quote make sure you include some contingency for the inevitable ambiguities and "mission creep" (make it part of your support costs), as specifications often evolve, since customers themselves often do not fully understand their own requirements until they see some working code. This way, when reasonably small changes are required, you can accommodate them (you can inform the customer of course that these changes take you beyond the original specs, but you anticipated that some changes may be necessary and these requests are not so extensive so you are willing to take the extra step.)

Fourth, if despite your precautions, you find yourself in this situation, it really becomes a judgment call. Are there signs that this is a "problem customer" who will never be happy? Then stick to the letter of your quote, and when new features are requested, provide them with an amended quote. (Even so, keep in mind that until you get paid, the problem customer holds all the cards, and if it becomes a matter of dispute, the burden of proof that you completely fulfilled your contract is on you. It is best never to take things that far even if it means swallowing your pride.) Or is this a customer with whom you have a collegial relationship that you have reason to expect to last a long time, with many more contracts coming your way? Then do what you can (within reason) to keep them happy (again, it is okay to inform them that what you did was a step beyond your original quote.)

One thing you should not expect is your customer to be "professional". That is your job: you are the professional here, the customer is just that, a customer. Of course it is good to have a customer who always acts professionally, but do not expect this. Do expect instead that customers often do not fully understand their own requirements; that part of your job is to help them understand their own needs and educate them about what can be provided; and when bridging the gap between customer expectations and feasible reality requires you to take an extra (small) step, consider taking that step without making a fuss about it.

  • 19
    The customer has already shown themselves to be a 'problem', it's complaining rather than discussing, and they didn't bother testing during the build, just complained at the end when they got billed. They don't deserve any sort of break. Good comprehensive answer though +1
    – Kilisi
    Commented Nov 7, 2016 at 2:16
  • 4
    @Kilisi This is my favorite answer. Having been a consultant for 30 years and now retired, I would say give them E, F, and G then expect to cut ties. I value customers that know what they want and have requirements ready to go. I only once agreed to develop anything for someone who was unsure. Of course, this was a disaster. I was a fool to agree to work with them in the first place. I found that I felt better giving them a bit more time before saying goodbye. The reason is simple. I gave them more than they agreed to. Any dispute would end in my favor. I considered it a lesson learned.
    – closetnoc
    Commented Nov 7, 2016 at 6:01
  • 1
    @closetnoc I also like this answer, know consultants who use similar strategies and I upvoted it, it's just not how I do things. I've also been consulting for decades and long since passed the guys who weren't ruthless enough.
    – Kilisi
    Commented Nov 7, 2016 at 6:29
  • 2
    @Kilisi I prefer to kill 'em with kindness. In my case, it was a no-win scenario. One in 30 years is not bad. It was a fill-in job between contracts. A simple VB job and when I delivered, they suddenly decided they wanted it all in Access. I am a system internals engineer. I know code! I wrote OSs, device drivers, protocol stacks, etc. VB was the right thing and what they asked for and signed off on. Access applications are a nightmare! After I delivered, I passed it off to an Access programmer and worked with him side-by-side until done. I gained a friend from the Access programmer anyway!
    – closetnoc
    Commented Nov 7, 2016 at 6:38
  • 1
    @Kilisi It just occurred to me... that the Access code had to be redone with every change in the companies requirements whereas my code was a complete solution. It was a medical survey application that allowed someone to specify a survey, push a button, and a survey executable was automatically created with install and export process to SAS written to a disk. Just minutes to do. As for Access, this required modifying the code for each survey and manually packaging the install and no export to SAS and no disk. In the end, it was sad to see my sweet code ignored. I feel vindicated anyway!
    – closetnoc
    Commented Nov 7, 2016 at 6:47

This is another case of a customer expecting a vendor to read their mind, and pushing the vendor around:

  1. Tell Mr. Customer that your quote was based on the specs that he gave for A, B, C and D. State categorically that he never said anything about E, F, G at the time he signed off on the quote.

  2. Tell him that while your review of E, F, G indicates that it will take only a few hours to complete, you regard this as additional work NOT covered by your original quote and that if he wants the work done, he will have to pay additional for additional work. Then send him an invoice for the original work.

  3. Don't do a stitch of additional work until and unless you have been paid for the original work.

Unfortunately, you will have to take the risk of not getting paid by a possibly unethical customer. If it's any consolation to you, it's always better for you to determine sooner rather than later that a customer is a black hole that sucks up your time and energy at the expense of your other paying customers.


Depends on size of the change. Your budget should have included some amount for customer support. If this can be covered under that, great. If not, offer quote for the additional work.

Note, however, that this is partly your fault. You really should have had the customer review sketches/prototypes earlier in the process, so they knew exactly what you were expecting to delver and had either signed off on that or had discussed changing priorities/budgets back when there was still a chance to address any concerns before delivery. There may be a legitimate argument that, having failed to do this, you owe them something.

  • 18
    As long as the project evolved, I asked them to test the incremental solution in order to get some early feedbacks. They said they did it, but eventually, they confessed they didn't (because of time (they argue)). They expect features totally implicitly.
    – Mik378
    Commented Nov 6, 2016 at 21:09
  • 10
    @Mik378 They said they did it, but eventually, they confessed they didn't Well, their fault. I agree that you just demand payment, and then (if they still want to) you can talk about the other features. (And If they don't pay soon, remember that you can demand some sort of delay fee in many countries).
    – deviantfan
    Commented Nov 7, 2016 at 3:09
  • 9
    @Mik378 - I think this is an essential point which should be included in the questions body! - Because you explicitly asked them to test it and they didn't - they have lost any standing.
    – Falco
    Commented Nov 7, 2016 at 10:01
  • 1
    @Falco, indeed I updated the question ;)
    – Mik378
    Commented Nov 7, 2016 at 14:34
  • During the project it would probably be good to asks for feedback and if you don't get it, tell them that i might have consequences. "I need you guys to do the tests, otherwise we might not detect issues before to late in the project " (i would step up casually, like). 1. Did you do the test, No? Can you do it next week shal we say deadline Wednesday?.
    – cognacc
    Commented Nov 10, 2016 at 10:10

I agree with much of what's been said, so let me just add a couple of points.

Could the client reasonably have expected E, F, and G to be included as part of A, B, C, and D? I mean, if this was, say, an on-line order system, and A was "customer can enter their delivery address, city, and state", and now they're saying, "wait, you didn't give us a place to enter zip code", I don't think you can fault them for thinking that was assumed under A. If now they're saying there should be a way to enter foreign countries, that's debatable, the sort of thing that should have been cleared up in early discussions. If it was mentioned in the specs/quote, you're justified in saying it's not covered, but, etc. If now they're saying that they want a weekly report of how many orders were received broken out by zip code and state and cross-reference by product category ... no.

I have fond memories of the client who, after delivery, asked how to get a certain complex report. I said sorry, no such report was ever mentioned in the requirements. And he said, "I just took it for granted that I could get any report I wanted at any time." Like yeah, that's how computers work on Star Trek.

If these new requirements are just a small extra percentage on the total project, I'd be inclined to give it to them for the sake of customer relations even though it was not in the quote. But tell them that you're giving it to them for the sake of customer relations even though it was not in the quote. Giving freebees with no caveats sets you up to be expected to do it all the time. It's been years since I've been a freelancer and I've never done this, but here's how I think I would do it if the situation came up now: Make the change, then send them a bill that says "Additional features E, F, and G ... 4 hours @ $150/hour (or whatever your rate is, obviously) ... $600. Write off for customer relations ... -$600. Net owed ... $0." Then you're telling them you did them a favor and exactly how big a favor, with no implication that you'll do it again. If anyone has tried something like this, I'd be interested to hear details and how it worked out.

You said these new requirements were just a few hours of work. But if it was a big deal, I'd be saying, "I'm sorry, but the quote covers A, B, C and D. If you have additional work you would like done, I'd be happy to prepare a new quote."

BTW You say that you provided the client with prototype versions or something of that sort along the way, and they apparently never looked at them. This is certainly not unheard of. It's happened to me, and then of course when they finally do look at it, they have a million changes. But it's a danger sign that this could be a problem client. If the client is willing to acknowledge that they never looked at things along the way and are willing to pay for rework, okay great. My company has a client like that now, they never look at things until after the project is done, so instead of making changes early when it would be easy we wait until the end when there is major rework. But they also don't balk much when we bill them for the time to do the rework. So I guess we're making more money this way, so we don't complain. But if they're not willing to pay for the rework, this is a problem client. I'd make an effort to make them happy this time, collect my money, and then avoid doing business with them in the future.

  • 1
    Very complete and interesting answer :)
    – Mik378
    Commented Nov 7, 2016 at 22:46

A few downsides

  1. Paid later
  2. Not paid for E, F and G
  3. You get I and J when you deliver E, F and G

If you really think it is just a few hours and will get you paid them maybe just do it. But it can get out of hand quickly.

Even if you do quote E, F, and G separate then I would still ask for payment on the first.

  • @cognacc Really I am supposed to know what EFG are? Ask the OP if he is sure it is only few hours.
    – paparazzo
    Commented Nov 10, 2016 at 10:36

In my opinion, it depends entirely on the type of client you have. If they are technically savvy and should know exactly what they need and are just using your services because they don't have the staff available then sticking within the defined work scope is the correct response.

On the other hand, if you took on a client knowing that they don't have the knowledge to know ALL the specific requirements they are going to need up front, then I look at it as they are also hiring your expertise to let them know what is missing. After all, you are the 'professional' developer, not them. Thus, if you should have 'reasonably known' that without the features they say are missing that the application won't meet their needs then some, if not most, of the blame is on you. In which case, you should learn from your mistake for next time, but try to keep the customer happy this time. Certainly ask for more but recognize your role in the missing functionality. Of course, 'reasonably known' is a bit of a grey area but I suspect you already know if you should have realized if the feature was needed or not already. If the missing functionality isn't something that a typical 'professional' developer should have identified as missing then stick with the contract terms.

  • This is an excellent point. An analogy: About a year ago I needed some repairs done on my house. I called a contractor and we signed a contract that they would do this work for, I think it was $1800. Then a couple of weeks later they called back and said, "Oh, we made a mistake, to do this job right we'd have to do such-and-such additional work. That will cost another $900." I immediately concluded this was a scam. I don't believe for a minute that they made a mistake. It was an attempt to get me committed to doing this job for a reasonable price, and then they jacked up the price. ...
    – Jay
    Commented Nov 10, 2016 at 3:38
  • ... I probably could have sued them for breach of contract and fraud. My point being: You're the expert. If you tell the client, what needs to be done to meet their needs is A, B, C, and D and it will cost $X, they may sign the contract assuming this is the total price. If when they see it doesn't meet their needs, you tell them that doing the additional work will cost extra, they may see it as a trick: you got them to commit based on a price they can afford, but now to do the REAL job you're demanding more. I'm not saying you were trying to trick them, sounds like a miscommunication to me...
    – Jay
    Commented Nov 10, 2016 at 3:41
  • ... But I could see someone who knows nothing about IT THINKING it was was attempt to trick them.
    – Jay
    Commented Nov 10, 2016 at 3:41

I've been on the customer end of "engineered software - vaporware" Building a new platform does take time and R & D. You delivered what the signed contract called for. Do you have a mechanism for ongoing support ? Do use this product for other customers? With both of these concepts, you can participate in distributed updates. You'll have to build a model you can maintain. The complexity and testing and confirmation of the next level of the product. You will have some customers (if their knowledge base allows) that insist on being beta-testers. You will have to inform them on both your and their expectations. Stay within that scope. That gives you a managable model for updates/upgrades, continued cash flow, and happy customers. IMHO JLH This is how I had to work with multiple vendors (mergers) implementiting a multi phase, multi level, ERP system for small colleges.

  • 2
    Welcome to workplace.stackexchange.com! As is, I'm not quite sure your answer actually answers the question. You may want to edit with a focus on presenting a possible solution to the problem as opposed to asking some questions and describing what you've done. Once you earn 50 reputation, you'll be able to comment on the question to request clarification from the asker to better inform your answers (such as Do you use this product for other customers?).
    – Chris G
    Commented Nov 8, 2016 at 1:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .