Software development contract: what it should include before you sign

Custom software does not exist when you pay for it: it is built over weeks or months, and in that time priorities shift, new ideas come up and someone has to decide what goes in and what does not. The contract is what both sides look at when that happens.

That is why a good software development contract is not measured by its length but by how concrete it is: what will be delivered, how you know it is done, how much is paid at each point and who owns what was built.

This guide explains what is worth putting in writing from the buyer's side. It does not replace a lawyer's review: before you sign, have someone you trust read the final text.

1. Scope: what the system does, for whom, and what is left out. A list of features and screens beats a general paragraph like «a sales system».
2. Stages and deliverables: what is delivered in each stage and where (a test environment or production), with an estimated date for each.
3. Acceptance criteria: how a delivery is reviewed, how long you have to review it and what happens if something does not work as agreed.
4. Payments: how much is paid and against what. The healthiest setup is paying per delivered stage, not per month elapsed or everything up front.
5. Changes: how something new is requested mid-project, who quotes it and when it goes in. Without this clause, every change turns into an argument.
6. Ownership: who owns the source code, the database, the designs and the service accounts (server, domain, email) when the project ends.
7. Confidentiality and data: what the provider can see of your information and your customers', and what it does with it at the end.
8. Warranty: for how long errors in what was delivered are fixed at no cost, and what counts as an error versus a change.
9. Support and maintenance: if included, what it covers, with what response times and at what cost. It is often better as a separate agreement.
10. Termination: how either side exits the contract, what is handed over in that case and what is paid for the work done up to that day.

It is the clause most often overlooked and the most expensive to fix later. If the contract does not clearly say that the source code and the database belong to your company, you can end up paying for a system you cannot move, cannot have another provider change, and cannot take with you if the relationship ends.

What it should say, in writing:

• That the source code developed for your project, and the rights to use and exploit it, pass to your company as each stage is paid or on delivery of the project.
• That you receive the complete code in a repository in your company's name, not just the running system.
• That the database and its content are yours, and you can export them whenever you want.
• That the server, the domain and the other service accounts are in your company's name, or are transferred at the end.
• Which pieces are not exclusive: open-source libraries or the provider's own tools used across projects. That is normal; what matters is that they do not stop you from operating or switching providers.

At Gridarco, on delivery, the code, the database and the service accounts are in your company's name. If you keep working with us, it is because it suits you, not because you depend on us.

Working by stages spreads the risk: you pay for something you can already use, and before the next stage you can reset priorities with what you learned. It is how we work, and what we explain in the guide on what to prepare before asking for a quote.

• The scope fits in one line and does not say what is left out.
• Most of the money is paid up front, before you see anything working.
• It does not mention the source code, or says the provider «grants a license to use» without saying until when or with what limits.
• The server and the domain stay in the provider's name with no plan to transfer them.
• There are no acceptance criteria: the delivery is «done» when the provider says so.
• Leaving the contract costs more than staying, or it does not say what you receive if you leave.

None of these signs means bad faith; often it is just a generic template. But they are points to get in writing before you sign, and a good provider should have no problem clarifying them.