Should client pay for things overlooked in the spec?

Question

For a client, I developed a web-application and took responsibility for the hosting of the site. They squeezed the price really low (fixed-price contract), but I wanted the project so took it anyway.

The system just records sales details and generates reports off this data. The information is sensitive to some extent, but not mission critical. It obviously wouldn't be ideal for this information to escape or the site to be hacked, but if it did it would not have some major financial implication.

The client is doing the final testing acceptance and have requested that the site be secured via HTTPS. This wasn't in the original spec (though admittedly the spec wasn't hugely technical, focusing mainly on functionality), so I thought I would just canvas your thoughts.

Do you think that any site with mildly sensitive data should use HTTPS? If you were the client would you be expecting this without needing it specified? Should I organise the SSL certificates and the time to implement this at my own cost? or should I say that it was not in the spec and that they will need to pay?

I want to offer my clients great applications that meet their expectations, and if this was a well paying project I would probably just take the hit on the costs without question. But the budget for this project was very low.

Answer 1

Your last paragraph is the essential one: You want a happy client you can reference in the future and/or get more work from in the future.

My first response is that yes, mildly-sensitive data should be processed over SSL and so the work to do that should have been covered by the contract; as a client I would expect it and as a contractor I would have expected to provide it (but I'd've discussed it with them at contract stage).

I would think the cost of the SSL certs, unless you can use them for more than just this client's stuff, should be covered by the client. But low-end certs (which is all it sounds like you need) are dead cheap these days (< $15 USD / year), so it may not be worth even bringing that up...

I think I'd cover it and let them know I'm covering it (without making a big noise about it).

Separately, FWIW, I'd recommend trying to go into a bit more detail in the specification stage next time. There's a balance to specification, but on fixed-cost contracts, you need to lean toward over- rather than under-specifying what you're going to deliver at that price.

Answer 2

This is their financial responsibility. There is a real cost to SSL, the certs themselves cost money for starters.

You can't request a house, then when it's done ask for an addition at no charge when it obviously costs time and money to build. This one goes back to the client, not out of your pocket. Be civil about it, but the cert cost at least, should be theirs.

Answer 3

My take on this is that you should have asked up front if the data is sensitive and would require securing. It's your job as the developer to know the questions to ask and, these days, it's unconscionable that you would omit to gather details on security requirements. Yes, the cost of the cert itself should be borne by the client -- you're simply charging back costs for things that they own -- but I don't think you should bill them for your time as it was your mistake that caused the spec to be incomplete in this respect. Had you asked the question and they initially said, "no," then my answer would be completely different. Customers who change existing requirements should be expected to pay for the cost of the change.

Answer 4

Do good and talk about it

..if you can expect to get more projects from this client you should do it for free.

Answer 5

This sounds like a familiar problem to me. As soon as you´ve implemented it, I wouldn´t be too surprised if they find another "obvious" point that´s missing.

Many customers, especially smaller ones, have problems recognizing the real work behind what they get. It seems like the better and easier you make their experience with your product, the more they want to tell you how little afford it is/was to create it. The price of their new kitchen is 10k, that´s fine for them, but a little clicky-clicky development has to be cheap.

Maybe you could have talked about SSL in the first meeting. But then again, why do they come up with it right now? They could have stated it earlier. My guess is that they have recently heard about it and want you to implement it, for free of course. I can imagine that they will read about another cool idea afterwards. And another one, and another one. The more you deliver, the more they expect. It´s fine - as long as they don´t want it for free.

I would recommend you to let them pay. It´s also a kind of education. You will probably find yourself in a bunch of work that´s not going to be paid otherwise.

Answer 6

It mostly depends on your project size and scope tmo and directly to the time you will take to make the modifications

For example if you took 2 years to build the whole thing and adding HTTPS is another 2 or 3 days then go for it. Inform the client of the extra work time it is going to require with non-technical details about what it implies. Make them (or do it yourself) reread the contract (is security really implied?).

Also you can get away sometimes with only the login page on https.

I dont think this really means a lot of extra work. Sometimes just explaining how much work it is then doing it will improve your appreciation by the customer, you're doing him a favor.

Another completely different solution would be to convince them that they dont need HTTPS. Prepare arguments for and against, like, protection against sniffing attacks unlikely to happen. Who are you really gonna thwart with this technology? Is it really appropriate? Then you can think of a quick ,fast to implement alternate idea

Answer 7

The answer is it depends.

What kind of contract do you have with your client? It's a fixed price contract or you can play a little with the price?

In any case a budget overrun will not make your client happy. However the SSL thing was not specified in the contract so you have no obligation in doing it. However think what will be your relation with this client in the future - if the SSL thing is a minor/moderate loss for you now but this client will bring you a fortune in the future then take it. If this client is not going to help you in the future and the loss is moderate/high then I would suggest to either not implement it or request additional funds.

Answer 8

1. Make them pay. Specially if they squeezed the price as you said.
2. Blame yourself, and remember it for the next time, that Fixed Price <=> Complete Specs !

Don't forget the good old rule that 20% of your clients will make 80% of your annoyances.
And 20% (hopefully a different one) will make 80% of your sales.
Don't be too kind with the first 20%. You won't get any reward for it.

Answer 9

It does depends, but also on how well do you get along with the customer.

I would bring it up. Be cordial about it, but definitely bring it up with regards to the contract. They may meet you 1/2 way. As other have mentioned, the SSL issue maybe a start to the slippery slope of project creep. It is one thing if they are willing to pay(that can be bartered too), quite another if they have expectations of free work.

Answer 10

You should eat the cost. As tvanfosson points out, there are certain things that a professional must anticipate in order to be considered a professional. Data security is one of those things.

In the bigger scheme, I would tell you that you should not consider this a cost so much as the price that you pay to learn a valuable lesson about the way things really work.

Also, adding certs to a site is not hard. So, if you haven't done it before, you should also view it as helping you add a tool to your toolkit that every web pro should have.