MKB Juristen drafts custom legal documents
It is best not to cobble together or copy important contracts, terms and conditions, and other legal documents yourself. We help entrepreneurs on a budget with customized legal solutions, clear costs upfront, and practical explanations.
- Custom contracts, terms and conditions, and legal documents
- Budget-friendly and clear about the costs upfront
- Request a free consultation or a no-obligation quote
Drafting General Terms and Conditions for a software company means establishing the rules regarding development, delivery, acceptance, intellectual property, maintenance, additional work, liability, and payment. Unlike a SaaS service, this revolves around the development process and ownership of the code — not access to an online platform. Below, for each section, it is outlined what should be included, which legal rules apply, and where software developers most often go wrong.
The short answer
- IP and licensing: regulate who receives the source code rights and under which license the customer uses the software.
- Development and delivery: working method, milestones, delivery dates and the definition of “finished”.
- Acceptance: test period, criteria, and when software is considered accepted.
- Additional work: how requests out of scope are arranged and invoiced.
- Liability and SLA: ceiling, excluded damages, maintenance, and response times.
- Payment: invoicing per phase, installments and right of suspension.
Intellectual property and licensing
This is the most important and most underestimated part. Whoever creates the source code holds the copyright in principle (Art. 1 Copyright Act). For a developer, this means that, unless otherwise agreed, you remain the owner of the code — even if the client has paid for it.
Choose consciously between two models:
- License. You retain the IP and grant the customer a right of use. Advantage: you can reuse (parts of) the code for other customers. Define the scope: exclusive or not, transferable or not, and for which users.
- Transfer. The client wants the full rights. That is possible, but the transfer of copyright requires a deed (Art. 2, paragraph 2 of the Copyright Act) — a single sentence in the terms and conditions is not always sufficient. Generally, charge a higher price for this.
Do not forget open-source components: mention that the software may contain third-party libraries with their own license terms.
Development, delivery and acceptance
Software development is a process with moments when something is “finished.” Without an acceptance policy, it remains unclear when you have delivered — and therefore when you may invoice. Document:
- Methodology and milestones. Phased delivery (for example, per module or sprint) with clear delivery dates.
- Acceptance test. The customer tests against pre-agreed criteria within a fixed period (for example, 10 working days).
- Fictitious acceptance. If the customer does not respond within the time limit, or puts the software into productive use, it is deemed accepted. Without this clause, a customer remains “not yet satisfied” indefinitely.
- Rectification of defects. Only shortcomings affecting the agreed functionality block acceptance — cosmetic points do not.
Additional work
Almost every software project grows during development. The client comes up with new requirements, the scope shifts. Without a clause regarding additional work, you perform this for free or disputes arise over the invoice. Therefore, arrange:
- That work outside the original assignment qualifies as additional work.
- That additional work is confirmed in writing (or by email) in advance.
- At which hourly rate or method additional work is calculated.
- That additional work may shift the original delivery dates.
Liability and warranty
Software contains errors — that is a technical fact, not a breach of contract. Nevertheless, a bug can cause damage to the customer. Limit that risk:
- Ceiling. Limit liability to, for example, the contract value or the invoice value over the last period.
- Exclude consequential damage. Exclude indirect damage: lost profits, lost revenue, data loss, reputational damage.
- Warranty period. Offer free repair of defects falling within the agreed functionality for a defined period.
- Limits. Please note: you cannot exclude liability for intent or conscious recklessness (Art. 6:233 BW).
Maintenance, SLA and payment
If your company also provides maintenance, an SLA framework should be included in the terms and conditions or in a separate maintenance agreement:
- Response times per priority (for example, critical failure within 4 hours).
- Availability and maintenance windows.
- What does and does not fall under maintenance (updates versus new functionality).
- Costs: fixed maintenance subscription or per hour.
For payment: invoice per phase or milestone, apply a payment term (e.g., 14 days), and include a right of suspension — in the event of non-payment, you may halt the work and restrict access to delivered software until payment is received.
Practical example
A developer is building a custom planning system for an installation company. Midway through, the client wants to add connections to two external systems. Because the terms and conditions include an additional work clause, this is quoted and invoiced separately, and the delivery date is shifted accordingly. Upon delivery, the client tests for 10 working days; after approval — or upon commissioning — the system is considered accepted and the final invoice follows. The intellectual property remains with the developer; the client receives a user license. A single set of terms and conditions prevents three potential conflicts here.
Honest recommendation
Tailor the terms and conditions to what you are building. If you are building custom solutions, IP, acceptance, and additional work provisions are the heart of the system — do not copy SaaS terms and conditions that cover subscriptions. The biggest risks lie in unlimited liability and a missing acceptance mechanism.
When do you *not* need a lawyer? For a simple, recurring, low-risk assignment, a solid template will suffice, provided you adapt it to your own working methods and demonstrably send it along with the quotation. As soon as assignments become larger, you reuse code, or clients impose their own terms and conditions, legal review is advisable — a single poorly formulated IP or liability clause can turn out to be costly.
Read more and arrange: what are general terms and conditions for a software company, have drafted: costs and process , and the general terms and conditions for a software company.
Frequently Asked Questions
Provisions regarding intellectual property and source code licensing, development and delivery, acceptance, additional work, maintenance and SLA, capped liability, and payment per phase. For custom work, IP, acceptance, and additional work provisions are the most important.
Unless otherwise agreed, the developer retains the copyright (Art. 1 Copyright Act), even if the client pays. Choose wisely: license (you retain the IP, the client receives the right of use) or transfer (the client receives all rights via a deed, Art. 2 paragraph 2 Copyright Act). Record the choice in the terms and conditions.
An arrangement that determines how and within what timeframe the customer tests the software and when it is considered accepted. Include a fictitious acceptance clause: if the customer does not respond within the timeframe or puts the software into use, it is considered accepted. Otherwise, you can never definitively deliver and invoice.
Stipulate that requests outside the original assignment constitute additional work, that additional work must be confirmed in writing in advance, stating the rate at which it is calculated and that it may shift delivery dates. Without this clause, you are effectively performing scope expansions for free.
Limit liability to, for example, the contract value, exclude indirect damages (lost profits, data loss), and offer a warranty period for the free repair of defects. Note: you cannot exclude liability for intent or willful recklessness (Art. 6:233 BW).
If you provide maintenance, yes. Include response times per priority, availability, maintenance windows, and the scope (updates versus new functionality). This can be done in the terms and conditions themselves or in a separate maintenance agreement to which the terms and conditions refer.
No. SaaS terms and conditions concern access to an existing service (subscription, uptime, cancellation) and miss the core of development work: source code ownership, acceptance, and additional work. For custom work, you need terms and conditions tailored to the development process.
