At delivery time, client criticises the lack of some features that weren't written on my quote. How to react?

Question

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.

EDIT-----

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.