The latest articles on DEV Community by OCTOPUS (@oct7pus). https://dev.to/oct7pus https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1235685%2F644868ac-ca7d-484f-8da7-222faa019fc9.jpeg https://dev.to/oct7pus en OCTOPUS Tue, 18 Aug 2026 09:53:12 +0000 https://dev.to/oct7pus/how-should-a-software-company-handle-non-billable-rework-when-the-client-only-pays-for-completed-105e https://dev.to/oct7pus/how-should-a-software-company-handle-non-billable-rework-when-the-client-only-pays-for-completed-105e <p>I work in a software development team where a single task typically goes through several people and stages:</p> <ul> <li>Product documentation</li> <li>Refinement / analysis meetings</li> <li>Development</li> <li>First code review</li> <li>Second code review</li> <li>QA / delivery</li> <li>Build and deployment</li> </ul> <p>So a single task can involve 4–6 people and significant engineering hours.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>I'm trying to understand how other software companies handle this situation.</p> <p>Some questions I'm particularly interested in:</p> <p>How do you distinguish between a genuine bug and a change in requirements/acceptance criteria?</p> <p>Who should financially absorb the cost of rework?</p> <p>Do you include an expected defect/rework rate in project pricing?</p> <p>How do you measure the financial impact of defective tasks?</p> <p>What processes have actually reduced rework — better QA, acceptance criteria, code review, technical analysis, automated testing, or something else?</p> <p>How do you handle this contractually with clients who refuse to pay for bug fixes?</p> <p>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?</p> <p>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.</p> <p>What would you change in this process?</p> freelance management software softwaredevelopment