What should a software development contract contain? A checklist before you sign

In most purchases you see the product before you pay. In software you pay for something that does not exist yet, and you describe it in words each side understands in its own way. The contract is the only place where "a complete system" turns into a list that delivery can be measured against. Most disputes in software projects do not begin with bad faith. They begin with a one-page contract.

A clear contract protects both sides. It protects you from paying for work you did not receive and from losing the code and accounts, and it protects the vendor from endless demands outside what was agreed. A company that welcomes clear clauses knows it will keep them, and one that avoids putting things in writing is telling you something about how it works.

Make the scope an annex to the contract, not a sentence in it. For a website: the list of pages and what each contains, the languages, the admin panel and what can be edited from it. For an app: the list of screens, the platforms, the backend and admin panel, and publishing to both stores. For a system: the modules, the roles and permissions, the reports, data migration and training.

Write three more things many people overlook. First, what is explicitly out of scope, such as writing content, photography or third-party service fees. Second, the client’s responsibilities and their dates: content, approvals, opening accounts. Third, the non-functional requirements: Arabic and page direction, speed, supported browsers and devices, and any regulatory requirement specific to your business, such as e-invoicing.

The simple rule: every payment matches something you receive and try. The common order is a payment at signing to start the work, one after design approval, payments as working parts are delivered, and a final one at launch or after final acceptance. The shares differ from project to project. What matters is that what you have paid never runs far ahead of what you have received.

Write each stage’s date and what is delivered in it. Write the response time on both sides, because the date is affected by late content and approvals as much as by late coding. You are entitled to ask before signing what happens if a stage date is missed, and to have the answer in writing, not spoken. Make clear whether the amounts include VAT, in which currency, and who bears transfer fees.

This clause decides whether you bought a product or rented one. Ask for explicit wording that the source code written for your project becomes yours, and when: with each payment or on full payment. Ask for it to be delivered in a repository you own, with a document explaining how to run and release it. Ownership of code you cannot reach is ownership on paper.

Watch for what is not new code. Every project uses open-source libraries, and some companies reuse their own ready components across projects. That is normal. What is needed is for the contract to state your right to use and modify them within your project with no later fees. And ask about any paid third-party licence the system needs in order to run, and who pays it each year.

The accounts matter more than the code in daily life: the domain, the hosting, the App Store and Google Play accounts, the payment gateway, the messaging provider and the analytics accounts. All are opened in your company’s name and with its email from day one, with the vendor given access. And the data, meaning customers, orders and content, is yours in every case, with your right to a full copy on request written down.

Without an acceptance clause the project stays suspended: the vendor sees it as finished and the client sees it as incomplete. A good clause sets how the work is presented for review, within how many working days the client sends notes, the difference between a defect and a new request, how many rounds of correction are included, and when the work counts as accepted.

A defect is the software behaving differently from what the scope says. A new request is something that was not written. That distinction settles most end-of-project arguments, which is why everything comes back to how precise the scope is. Contracts commonly state that the client’s silence after the review period, or actual use of the system, counts as acceptance, so read that clause and make sure the period is long enough for you to test properly.

Ask about life after delivery before you sign, not after. Ask for it in writing: what is fixed at no charge and for how long, within how many hours a fault that stops work is answered, which channels are used, and what a maintenance contract costs afterwards. As a market reference, yearly maintenance runs at 15% to 20% of the build cost for websites and apps and 15% to 25% for internal systems, and monthly support plans at SAR 1,500 to 12,000.

Change requests will happen in every project, and that is not a fault. The fault is having no procedure for them. The sound procedure: the request is written, the vendor replies with its effect on cost and time, the client approves in writing, and then it is done. That way you are not surprised by a bill at the end, and the vendor is not surprised by a scope that doubled with no agreement.

If you will share information about your business before contracting, ask for a non-disclosure agreement. Inside the contract, state what counts as confidential, who may see it, and how long the duty lasts after the contract ends. If the system processes personal data of your customers or staff, Saudi Arabia’s Personal Data Protection Law places duties on you and on whoever processes the data on your behalf. The contract should state where data is stored, who can reach it, and what happens to it when the relationship ends. Your adviser or the regulator confirms exactly what is required of you.

The termination clause is what protects you if things do not go to plan. It sets when each side may stop, what is handed over at that point, and how the amount due is worked out. The fair principle: the client receives everything completed, with its code and accounts, against what has been paid. Governing law, the forum for disputes, compensation and limits of liability are purely legal clauses for your lawyer to draft.

At Fortune Code we work with a contract and a written scope before any work, payments tied to delivery and a written delivery date we keep. The code and accounts belong to the client, and we sign a non-disclosure agreement on request. We send a written quote within 24 hours, with fast technical support after launch.