5

I hired a WordPress developer to help with some customizations. We agreed on a fixed contract amount with fixed hours. When the developer delivered the product, there were several major problems with it (all within the scope). She spent several more hours fixing the bugs. Now she is charging for the extra hours spent on this. Our contract didn't specify how this would be handled. Is this normal practice? Shouldn't the product function as we greed, before I pay extra?

1
  • Contracts are there to deal with matters when things go wrong...
    – Andrew
    Dec 14, 2021 at 9:30

2 Answers 2

5

If the contract didn't specify what the deliverables were, then you are forced to negotiate that later. In this case, you have conflicting deliverables - so many hours of work, vs. fully debugged effort. So, you need to negotiate which deliverable is satisfying the contract.

In most cases with software development, it is not possible to guarantee all three of "fixed price", "hours of work", and "fully debugged product". In most cases, to get fully debugged product, the price and hours of work are open ended as bugs can be found in almost every product out there and can be found years later. Most software is delivered when someone decides that the remaining bugs are acceptable for today.

1
  • Thanks, learned my lesson.
    – 3xK
    Nov 29, 2021 at 18:38
3

I agree with DavidR's response completely. To help going forward, I'd suggest a very clear delivery spec. It doesn't have to be exhaustive, but there should certainly be clarity on what is considered "delivered."

For example:

  1. discrete list of requirements (functionality, UI, data, operational, etc.)
  2. discrepancies/errors/bugs related to (1) are known as DEFECTS and will be considered 'on the table' to fix before delivery within current contract.
  3. with (1) and (2) accepted, the product is "delivered"; current contract concludes with payment.
  4. anything beyond (1) and (2) is negotiable for delivery or beyond -- but you have to accept being charged for it

"Good enough" is a concept for determining how (3) is realized. As DavidR mentions, there are always more things to discover over time.

Personally, I fix DEFECTS on my time as I should have caught them in my own QA; even if they are exposed after delivery (i.e. both the client and myself missed them during QA). Then again, I'm fairly rigid about requirements up front just to keep it clear for all parties; this minimizes my exposure to DEFECTS.

1
  • The 4 steps you mentioned are excellent. I will include in my contracts going forward.
    – 3xK
    Dec 1, 2021 at 21:52

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.