What is the practicality of asking vendor to not include a specially developed feature in their standard package offering

Question

I don't know if this is the right place to post this sort of question, so feel free to move it.

Lets say that Vendor X is selling a certain software package. There are also other competitors, including Vendor Y, selling similar software packages. My company is leaning toward purchasing the software package from Vendor X, probably due to our long working relationship with the vendor.

For various reasons my company requires a certain software feature. Vendor X's software package does not include this feature, but Vendor Y's software package does. This feature has nothing to to with our company or environment, but is a general feature that other companies with similar needs could also benefit from (which is probably why Vendor Y offers this feature as standard).

The quote given by Vendor X for the development cost for the feature in question was a little high. Also Vendor X's package is newish, whereas Vendor Y's package has been around a long time and has many customers. I am in favor of using Vendor Y's package, but most most other people prefer Vendor X's package most likely due the past working history of our two companies. I have a feeling that in the end Vendor X's package will be chosen regardless of the cost. Given this, I want to try to get Vendor X to reduce their estimate to minimize the blow somewhat. (For the record, we have not yet received an estimate from Vendor Y even though we have been waiting months. There is some potential weirdness going on, but for the sake of simplicity I won't elaborate any further.)

Would it be unfair or unusual to ask Vendor X to reduce, or possibly eliminate, the development cost for the feature that arguably could be used to add to the overall desirability of the package in the software market? Is this an atypical thing to request? BTW, we asked casually about this once, but the vendor said no. (I have a feeling that Vendor X is aware of their status as preferred vendor and so is using that to their advantage the best they can.)

If Vendor X does not budge on the development cost, would it be impractical, unorthodox, or maybe even crazy to require that the vendor not to use any of the code used in the development of our custom feature in the standard package that they sell to other customers? How would that even work anyway?

Answer 1

Having been on the other side of this, I can say the following:

• This feature will require on-going maintenance, so the quote you have is most likely lowballing the actual cost to the vendor of building and maintaining the feature. Customers always were surprised by how high our quotes were, and at the same time the developers always felt we were low-balling it. Building and maintaining software is expensive.

• The price you received likely assumes that this feature becomes part of the standard product. If the feature is entirely custom, they will have said so, and it will come with different support arrangements (basically the cost of maintenance of the feature on future releases will be placed with your company, not with the vendor).

• You can always haggle over the price. Most of the time when a customer pushed back on a quote we would lower it. Most of the time the actual cost of the feature would end up exceeding not only the reduced quote but also the original quote.

• Many "standard" features in an industry do not affect a purchasing decision at all. In order for a feature to be worth building, it shouldn't just be useful to users, it needs to win sales. The amount of sales that hinge on any particular feature are low. Probably your feature doesn't matter as much as you think.

So, to answer your questions:

• It is pretty common to push back on a quote for building a feature and get a revised lower quote. Standard haggling tactics apply (it doesn't matter what you're haggling over.)

• Asking them not to include it standard is an option, but it will mean your company will be fully responsible for the maintenance cost, and will be worse off as a result.

Answer 2

On the technical side, it all depends on how integrated the desired feature is within the other features, and how extensible the package is.

If it is an isolated feature (e.g. an additional report, an interface, ...), and the package is configurable:

• you can very well consider developing the feature on your own or by a subcontractor. This will be your BATNA: best alternative to a negotiated agreement.
• the vendor can easily keep the feature separated from the main product.

If it’s a deeply integrated feature (e.g. some additional validations that have to be performed in dozen of windows for a given business process), or if the package is not extensible (e.g. only vendor can extend it, proprietary knowledge, no possibility to configure what you want), then the choice has to be made at the package level.

Moreover, it might be difficult for the vendor to manage several versions in parallel if the feature is deeply integrated. That will be his main constraint.

On the non-technical side, it’s a combination of negotiation skills, commercial interest and legal expertise. All three are out of scope here. Nevertheless, the usual argumentation line is the following:

• either you pay the full price, and the vendor is not authorised to use this development with other customers.
• or the vendor shares the cost with you, and integrates the feature to which you will participated somehow (specifying, validating/testing) in his product for the benefit of all. It can be mentioned that if Y has this feature, your cost sharing arrangement can help the vendor to become more competitive.
• an unpractical alternative is that you pay the full price, and the vendor reimburses you a part every time he sells the additional feature.

Once a commercial agreement is found, the legal experts will find the words to describe the matters in terms of intellectual property and licensing.

Answer 3

Developing a feature is expensive. Developing a feature specifically for you is very, very expensive.

The cost is the development cost, calculated in a realistic way (say £1,500 per developer day), the eternal cost of maintenance for a modified version, the cost of additional testing, and a big chunk the cost of not having these developers there to do what the company wants them to do.