Software development contracts: what must be in writing

Most fights between a company and its software vendor don't start in the code. They start with a sentence nobody wrote. What did “done” mean? Who pays for the change that came up midway? Who owns the repository? When the project goes well, these questions never come up. When it runs late, they become the whole project.

The contract is the only place where these answers get recorded before the problem shows up. In this guide I list what needs to be written into a software development contract, from scope to source code, along with what Brazilian law already says on the subject. This isn't legal advice: it's the checklist of someone who has seen a lot of projects start and finish.

Why the vendor's standard contract usually protects only them

Every vendor has a contract template. That's normal. What you need to understand is that the template was written to reduce the risk of whoever drafted it. Vague scope clauses, “estimated” deadlines, code delivered only at the end, and a license to use instead of ownership are common.

None of this is illegal. But all of it pushes the risk onto you. And you usually only notice when you want to switch teams, as we covered in the article about the freelancer who vanished with the project. Reading the contract with the list below takes an hour and saves months of pain.

The 9 clauses your contract needs

1. Scope defined by deliverables, not hours

The scope should say what users will be able to do in the system: place an order, approve a payment, generate a report. “Web platform development” is not a scope. Attach an appendix to the contract listing the screens, user roles, and integrations (payment gateway, ERP, WhatsApp). What isn't in the appendix isn't in the price, and that applies to both sides.

2. Written deadline, with milestones

An “estimated” deadline is not a deadline. Ask for a final date and interim milestones, each with a deliverable you can open and test. Also write down what happens if the deadline slips because of the vendor: a discount, a penalty, or the right to terminate without paying the next installment.

3. Price and payments tied to deliverables

Paying by milestone protects the client. You pay when you receive something that works, not when a month goes by. Be wary of contracts with most of the amount paid upfront and of price adjustments with no defined index.

4. A rule for scope changes

Every project changes. The problem isn't change, it's having no rule for it. The contract should say how a change is requested, who approves it, how the impact on price and deadline is calculated, and that nothing new starts without written approval. A better option is to swap one feature for another of the same size, without touching the date. We explain this logic in cutting scope to hit the date.

5. Acceptance criteria

What does “delivered” mean? The contract needs to define a testing period after each delivery, what counts as a defect, and the deadline for fixing it. Without that, the vendor considers it delivered the day they publish it, and you find the bugs on your own.

6. Ownership of code, files, and accounts

This is the most important clause. Article 4 of Brazil's Software Law (Law No. 9,609/1998) says that, “unless otherwise agreed,” the rights to a program developed during the contract and for that purpose belong to the client. Sounds settled, but the exception is exactly the point: all it takes is one clause in the vendor's contract saying they keep the rights, and you get only a license to use it.

And those rights last a long time. The same law protects a program for 50 years, counted from January 1 of the year after its publication or creation. Write it down with no room for doubt:

• the source code, design files, and documentation belong to the client;
• the repository lives in your company's account from day one, with access for the vendor, not the other way around;
• domain, hosting, database, transactional email accounts, and app store accounts are registered in your company's name;
• third-party libraries and components the vendor reuses from other projects are listed, with each one's license.

7. Data protection (LGPD)

If the system handles data about customers, patients, or employees, your company is the controller and the vendor is the processor of that data. The LGPD requires the processor to handle data according to the controller's instructions, and a processor that breaks the law is jointly liable for damages.

The stakes are high. Under Article 52, a simple fine can reach 2% of the company's revenue in Brazil in the previous fiscal year, capped at R$50 million per violation, as detailed in Aurum's commentary on Articles 52 to 54. The contract needs to state where the data is stored, who can access it, which security measures are mandatory, how quickly you're notified of an incident, and what happens to the data when the contract ends.

8. Warranty and support after delivery

Defects show up after the system goes live. The contract should include a warranty period during which bugs are fixed at no cost, and clearly separate a defect (something that doesn't work as agreed) from an improvement (something new). If there's maintenance after that, it needs its own contract, with a defined response time.

9. Exit: how to leave with everything

Nobody signs a contract thinking about the end, which is why this clause is often missing. Write down how either party can terminate, what gets paid up to that point and, above all, the obligation to hand over up-to-date code, accounts, documentation, and passwords within a few days. A contract with a good exit is what lets you switch vendors without bringing your company to a halt.

Red flags before you sign

Some phrases deserve a second read, and a direct question to the vendor:

• “The code will be delivered at the end of the project.” Why not from the start, in a repository you own?
• “Estimated timeline of X weeks.” What happens if it runs over?
• “Software license to use.” Are you buying a system or renting one?
• “Changes will be quoted separately.” What's the rule? Who approves?
• No mention of personal data in a system that will clearly store customer data.

If the vendor resists changing these points, that says more about the relationship than any portfolio. More questions worth asking are in questions to ask before hiring a software studio.

What this means for you

Before asking for a quote, decide three things: what needs to be live in the first version, which date matters for your business, and how much you can invest. With that, the vendor can run a discovery and lock in scope, price, and deadline in writing. Without it, any contract becomes a gamble.

Then read the contract with this list. Ask to change anything vague. And if the project involves sensitive data or a large sum, take the text to a lawyer before signing.

How we do it at the Studio

At Studio Responsivo, the price is fixed after discovery and the deadline is written into the contract. The code, files, and accounts are in the client's name. The dev team is the Studio's own, so the people who sign are the people who deliver.

That's how it went with LCX, a travel company operating in more than 10 South American countries: one system per country became a single system, live in 29 days. Every system we deliver ships with an AI agent that runs daily, flags failures, suggests improvements, and checks that the data makes sense.

If you're about to hire a team to build a system and want a contract that states, in writing, what's included, when it's delivered, and who owns it, see how we ship custom systems and SaaS.