> If the product contains bugs/manufacturing defects/etc. then i expect the manufacturer to either fix those or refund me.
This analogy doesn't work with software. If you put your fridge in your house and your power goes out, you can very clearly see that your fridge is inoperable because of your power, not the fridge. Now let's try this with software:
- The software you buy supports Linux v16 but not v18. You upgrade to v18 not knowing and not your software is broken. But the software was sold to you to support v16 and not v18.
- The software you buy supports API connections to Twilio. In the docs it says "easy to use extensible API for all SMS providers". Twilio discontinues its v1 API endpoint but your software only supports v1 and not v2. You decide to migrate to Plivo and everything works except for one API call that is used once every 3 months.
And on and on and on...see the point?
> I am asking you to provide to me exactly on what we agreed upon in our contract.
Great, now the developer not only has to be a "good developer" but also an expert in contract writing (or has a lawyer that is). Or worse, the lawyer and developer must be completely and harmoniously in sync about product functionality and the contractually nature that you, the client, originally decided to sign the contract with. Note - In case you are unaware, software contracts are notoriously difficult to do well (see Google/Oracle debacle).
> If I buy a product I expect that product to perform as was promised. If it does not and the manufacturer refuses to work with me then it's a breach or contract.
I think you're going to find the more and more you explain your position the more and more you'll see that "why is this so hard" is truly...hard.