4

We had developed a custom solution from scratch for our client. Recently the client asked for a quotation to integrate it with a third party software.

Unfortunately, we merely received a hastily guided demo of that software from its vendor, a demo API endpoint, and some paltry 'documentation' containing examples on how to call the API with no explanation of the data returned whatsoever. We've asked for more documentation or at least demo access to that software so we can 'reverse engineer' the API (kind of silly, I suppose) but unfortunately the vendor refuses to give any of that unless our client signs a year long contract with them.

Given the massive lack of visibility on this, I am hesitant to provide any kind of quotation. However, I was pressured into giving one, so I quoted a high price for it to cover the risks involved.

Of course, the client is unhappy with this and claims he can't afford to pay for it. Furthermore, somehow it seems that vendor has told the client that they can do the integration themselves at a much lower price by modifying our software.

While the code we've written now belongs to the client and they can do whatever they want with it, how do I tell them this is a very bad idea and will most likely fail? Also, the client is still paying us for software maintenance, so we would like to keep the code in a good state and of course, we would not want to be blamed (or be fixing) for any issues that might arise from the vendor's changes.

  • What is the cost of unintegrated code? – Mark C. Wallace Jul 18 '16 at 12:32
  • @MarkC.Wallace Can you clarify what you mean? – Barry A. Jul 19 '16 at 10:02
1

Presumably your client has shown your code to the third party and being in possesion of all the information they have less risk to cover than you when making their bid.

However, your client has the risk that they are simply putting in a low bid so that your client buys their main software and they might never deliver on the integration work.

Rather than try to explain your risk to the client. Highlight their risk with the third party option by saying:

1- Any changes to the code run the risk of breaking existing functionality

2- You are unable to continue supporting the product if changes are made to the code. Will the third party take over this support for the WHOLE product?

3- If the third party fails to deliver, or bugs are found after the work is comple and your client comes back to you to fix the problems. The costs are likely to be of a similar amount to you doing the work in the first place.

4- Suggest that the third party simply wants to sell their off the shelf product and has no interest or stake in the integration work. Where as you are committed to on going support and quality.

| improve this answer | |
  • Additionally, you could share the benefits of the long term relationship the Client shared with you while working on the main Project. For them it would be 'Penny wise and Dollar fool' idea to expose your code to a Third party for an integration work. Where, the possibility of adding more issues by them is higher. This in turn would have a greater impact on the current system. – Anurudh Singh Jul 19 '16 at 4:26
  • Possibly you could recommend a competing product with better documentation of apis – Ewan Jul 19 '16 at 7:31
  • Thanks for the answer. I've pretty much given up on trying to explain this to client. To him code is code and any development company can simply modify someone else's code without any difficulty or introducing any problems at all. – Barry A. Jul 19 '16 at 10:15
  • urg what a pain, I can only suggest you reduce it to the support contract, which is your only real leverage. If you do the work the contract remains in place, if they do the work you will up the support price. But its not a great sales pitch – Ewan Jul 19 '16 at 10:19
3

You consider the vendor a large risk, which in a fixed price situation means you have to cover it. Your quote is you honest assessment and you'd be foolish to lower it. I hope you've explained your reasoning to your client.

A time and materials contract would be better for both of you. You don't take on that risk (specifically you don't run the risk of being hung out to dry by your client's unreasonable vendor / your snubbed ex competitor). As the customer doesn't have to cover your risks, they get a fair price. The customer seems to trust the vendor more than you, and given his direct relationship with them is probably better placed to encourage their cooperation. I don’t think it would be hard to convince them that T&M is the cheaper route here.

While support contracts are a great source of recurring revenue, hopefully involving little actual work. Supporting your code after modification by a third party is not something I’d want to get into. While the T&M route should be presented as the probably cheaper heaven if they do, you sell this mess of (expensive for the customer, hopefully) software support as the hell if they don't.

| improve this answer | |
  • Thanks for the answer. This was my original proposal but the client insists on a fixed price (and time). Hence, my conundrum. Now it's clear that the client is choosing the vendor instead. I honestly cannot imagine how they can do it in the timeline since it is not their code and we use an custom in-house technology stack. At this point, I don't care about the job, I just want to minimize any potential damage this situation might cost us since unfortunately the maintenance contract is already in place. – Barry A. Jul 13 '16 at 4:26
  • 1
    @BarryA. Did you promise to support arbitrary modifications to you code? I hope not. – Nathan Cooper Jul 13 '16 at 6:58
  • Of course not. I intend to include a clause that says the vendor is responsible for fixing any issues they introduce. – Barry A. Jul 14 '16 at 5:13
  • 1
    Bear in mind if they make the code suck, it's going to be harder to diagnose and fix your issues. Also, you'd need to prove it was them. – Nathan Cooper Jul 14 '16 at 7:34
1

A lot of my experience comes from the architecture/construction world and I think that there is a billing model you can borrow. Typically, the initial "schematic design" phase is billed by the architect on an hourly/time and materials basis and only after that is complete is the "construction documents" contract signed and the price set.

It might be worth it to try a two-phase approach: a initial development phase (call it "suitability study", "preliminary development", or something) at time and materials contract and a more normal contract to be determined at the end of the initial phase.

During the initial phase, you do need to have meetings and discussions with the client. You don't want to over-spend the client's willingness to pay.

| improve this answer | |
  • Thanks for the answer. As I said, the vendor refuses to engage with us for any kind of study of their system until the client signs a contract with them. And the client refuses to sign a contract with them until we sign off on a price and timeline that he finds 'acceptable'. – Barry A. Jul 13 '16 at 4:41
0

Many customers can't stomach T&M so you are forced to do a fixed price quote - this is pretty common.

Can you do a fixed price quote for a Proof of Concept or a Minimum Viable Solution? Which 3rd party API, integrated with your solution, provides the most benefit with the least amount of risk?

Quote the MVS/PoC work with some contingency and set the expectation that the rest of the work can be quoted once the PoC is done.

At the completion of the Proof of Concept it should be pretty clear what your capabilities are, what the 3rd party team can handle, and the customer should have a good idea about who can actually deliver on time and on budget.

If all goes well and the 3rd party team is great, then your risk & price go down.

If it doesn't go well, then your customer should understand the source of the problem, and your price will make sense.

It is crucial that your customer knows that the complete solution will be an iterative process and you will be coming back to the well for more money. The customer should appreciate this approach because small projects succeed far more often than large projects: Gartner Survey

| improve this answer | |
  • Thanks for the answer. It is clear now that somehow my client has 'no choice' but to choose this vendor. We've already researched similar solutions and there are many competing ones that provide much better features, have extensive and clear documentation, provide self-service trial access and costs lower than this one. I suppose right now all I can do is to minimize the damage the vendor can inflict into our code. – Barry A. Jul 19 '16 at 10:09
  • Good luck Barry. Customers make interesting decisions and can put us in difficult spots. – Shmoken Jul 20 '16 at 21:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.