When the Client Requested the Source Code After Project Delivery

One of the topics that should be clarified at the beginning of every software project is how the source code will be delivered and who will have the rights to it. An experience from one of my projects made the importance of this issue even clearer to me.

A Real-World Experience: When the Source Code Became an Issue After Project Completion

In one of my projects, which involved a shareholder management system for a public company, the client requested that the complete source code be handed over after the system had been deployed and the final payment had been settled. They wanted their own programmers to be able to develop the system further.

This raised the issue of source code ownership and became a point of disagreement.

I explained to them that, according to the contract, the rights to the software source code belonged to the project developer, and that transferring the source code was a separate matter from delivering and using the software.

I told them that if they wanted the source code and its technical documentation, this would need to be agreed upon separately, and the cost would also be calculated separately.

Why Did I Ask for a Formal Request?

I asked them to first submit their request in an official letter so that the matter would be clearly documented and could be formally referenced. I would then respond with a letter clearly defining the conditions for delivering the source code, technical documentation, and the responsibilities related to future development and modifications of the software.

The reason was that after receiving the source code, further development and modifications would be carried out by the company’s programmers. Therefore, it was necessary to clearly distinguish responsibility for the results of changes made outside the scope of the original project under the new circumstances.

They initially agreed to this.

But Something Else Happened

Some time later, without any prior notice, I found out that they had abandoned the system and decided to rewrite the software from scratch as a separate project.

I was not upset that they had decided to stop using our software; the final decision about whether to continue or discontinue a software system belongs to the client. What I found worth considering was the way resources were being managed.

The previous system had already been designed, developed and deployed, and its costs had been paid. Therefore, completely rewriting a similar system could mean spending time and financial resources again on work that had already been completed.

Of course, it would not be possible to fully judge the company’s internal decision, because there may have been other reasons for rewriting the software. However, in my view, such decisions should be made after carefully evaluating the cost, time, condition of the existing software, and the actual benefits of replacing it.

Read the Contract Before Signing It

One interesting aspect of this project was that the client had not fully read the contract when it was signed and had simply signed it.

As a result, when they requested the source code after the project was completed, they only then realized that ownership and transfer of the source code had been clearly addressed in the contract and that source code delivery was not part of the project’s original obligations.

What I Learned From This Experience

This experience taught me an important lesson:

In a software project, do not discuss only features and delivery timelines; source code ownership, how the software may be used and developed, and responsibility for future changes should also be clearly defined before the collaboration begins.

Perhaps even more importantly, the contract that will serve as the basis for the collaboration should be read carefully before signing. Many disagreements arise months later, when the parties realize that they never actually reached an agreement on an important issue in the first place.