Bugfix

I know a company where developers fix bugs for free. Presumably, this company follows the logic that "If there are bugs, it means the developer did a poor job!"

Of course, to prevent losing developers in such a situation, the company either needs to pay them a lot (but that's not the case with the company I mentioned), or the developers need to be hypnotized, and their will must be suppressed, or the developers should belong to an oppressed group and have no way to escape from this company.

But, who should pay for bug fixes if we're serious about it? The client, the agency, or the developer?

As practical experience shows, the majority of bugs in no-code arise from imprecise initial requirements. This is because tactically when creating specific functionality in no-code, it's quite challenging to make a serious mistake. Of course, there are complex tasks that are resolved through what they call "workarounds," and in such cases, the likelihood of errors during development is higher. However, in the case of regular functionality, it takes a significant effort to make a substantial mistake.

So, it turns out that the main source of bugs in no-code is poorly constructed documentation. It's often not well-prepared and not approved before development. Often, the client didn't even create it. The project manager didn't remind them, didn't inquire, and didn't double-check. Therefore, it's by no means certain that the developer should pay for these mistakes.

There are situations where developers are simply paid for all the hours they track on a project. The developer just waits for bugs, fixes them, tracks hours while doing so, and sends it for testing. Then, they fix it again and track hours, even if it's the second, third, or tenth fix for the same functionality.

I know a story where a developer tracked about 40 hours for creating a simple SMS-based login in a Bubble application. He spent 3 hours on the login itself, and the rest of the time was spent fixing bugs. Initially, the bugs were not his own but were related to errors in the requirements. Then, he had to redo everything because the client changed their mind about using SMS, and he got confused about the project, so he had to fix his own bugs. (On top of that, he tracked about 6 hours of video calls with the project manager).

And the funniest part is that even after this developer left, the login in the application still didn't work.

So, what can be done to avoid suffering in such situations?

First of all, you need to create a separate task for requirements verification, including hours for testing and fixing bugs in the requirements.

You should also include bug fixing in the development task estimate and fix the number of hours.

Do not consider the task closed until it is accepted by QA.

Do not report it to the client until it is closed, and do not pay the developer until it is delivered.