I work in a software development team where a single task typically goes through several people and stages:
- Product documentation
- Refinement / analysis meetings
- Development
- First code review
- Second code review
- QA / delivery
- Build and deployment
So a single task can involve 4–6 people and significant engineering hours.
The problem is that our client has recently stated that they will only pay once for a task that is successfully completed and accepted. They will not pay for bug-fixing/rework, especially for newly developed features.
For example, if a task takes 15 hours across several people, but after delivery a bug is discovered and another 5 hours are spent fixing it, those additional 5 hours are considered non-billable. In some cases, the original effort effectively becomes a financial loss for our company.
The bigger problem is that some tasks go through multiple reviews and still come back with bugs. We currently have a significant number of these tasks, so the accumulated non-billable effort can become substantial.
I'm trying to understand how other software companies handle this situation.
Some questions I'm particularly interested in:
How do you distinguish between a genuine bug and a change in requirements/acceptance criteria?
Who should financially absorb the cost of rework?
Do you include an expected defect/rework rate in project pricing?
How do you measure the financial impact of defective tasks?
What processes have actually reduced rework — better QA, acceptance criteria, code review, technical analysis, automated testing, or something else?
How do you handle this contractually with clients who refuse to pay for bug fixes?
Is it reasonable for a client to pay only for the final accepted task regardless of how much internal work was required, or should the contract explicitly define a warranty/bug-fix period?
I'd especially like to hear from people who have managed software teams or client projects under a fixed-price or per-task billing model.
What would you change in this process?
