Blog - Syntanea

A custom software development contract checklist saves you from expensive ambiguity

A custom software development contract is not paperwork you finish after the real decisions. It is where many of those decisions live. Scope, ownership, acceptance criteria, support, security, payment milestones, and exit terms all become practical once somebody has to write them down.

Most software disputes do not start because a vendor wants to cheat a client. They start because two reasonable people thought the same sentence meant different things. "User management included" can mean a login form and password reset. It can also mean SSO, roles, audit logs, account approvals, and admin impersonation. Those are very different projects.

Use this checklist before you sign. It is not legal advice. It is a buyer-side sanity check for founders, operations leads, and managers hiring an external software team in Europe.

Define the software scope in plain language

Start with the business outcome, then describe the software in enough detail that a stranger could understand what is included. Avoid a contract that only says "build a CRM" or "create an AI automation platform." Those labels are too wide.

A useful scope section answers these questions:

Who will use the system? List roles, not only departments.

What are the core workflows? For example: create a quote, approve it, send it to the client, record acceptance.

Which integrations are included in version one? Name the systems and the direction of data flow.

Which devices and browsers must be supported?

What is explicitly out of scope? This matters as much as the included work.

If the scope is still moving, do not force a fixed-price build contract too early. Run a short discovery phase first. A two-week discovery can be cheaper than arguing about a six-month project built from guesswork.

Put deliverables and acceptance criteria in the contract

A deliverable is not "the application." Break the work into things you can inspect: clickable prototype, API specification, staging release, migrated data sample, admin panel, test report, deployment runbook.

Each deliverable needs acceptance criteria. Keep them concrete. "The invoice import works" is weak. "The system imports 1,000 invoice rows from the supplied CSV template, rejects rows with missing VAT ID, and shows an error report to the finance user" is better.

Good acceptance criteria reduce awkwardness. The client knows what to test. The vendor knows what counts as done. Nobody has to turn a demo call into a negotiation about feelings.

Clarify intellectual property and source code ownership

For custom software, the client usually expects to own the code after payment. Put that in the contract. Also decide what happens with reusable vendor libraries, open source components, design assets, infrastructure scripts, and internal tools the vendor already had before the project.

A clean IP clause should cover:

Who owns newly written source code after invoices are paid

Whether the vendor may reuse general knowledge or non-client-specific components

Which open source licenses are allowed

Where the repository lives during development

When the client receives full access to source code, documentation, and deployment credentials

Do not wait until the final invoice to ask for the repository. The safest setup is simple: the project lives in a GitHub or GitLab organization the client controls, with the vendor added as a collaborator.

Set payment milestones around real progress

A common structure is 20-40% upfront, then payments tied to milestones. That can work if the milestones match usable progress, not calendar dates alone.

For example:

Discovery and technical plan approved

Prototype accepted

First production workflow working on staging

Integration testing passed

Production release completed

Avoid paying 80% before you have seen working software. Also avoid starving the vendor with tiny payments that require constant invoicing. Both sides need cashflow that matches the risk.

Handle change requests before they happen

Every custom software project changes. A process that looked simple in week one turns out to have three approval paths. An API has worse data than expected. A stakeholder remembers a reporting requirement after seeing the prototype.

The contract should say how changes are requested, estimated, approved, and billed. It should also say who can approve them. Without that, a casual Slack message can become a scope dispute later.

A practical change request rule is short: document the requested change, estimate the impact on cost and timeline, get written approval, then start the extra work. If the change is tiny, bundle it into the next milestone review. If it changes the product shape, treat it seriously.

Include security, GDPR, and data handling terms

If the software processes customer data, employee data, invoices, health records, or anything commercially sensitive, security belongs in the contract. For EU clients, GDPR is not optional. You may need a data processing agreement alongside the software contract.

At minimum, clarify:

What data the vendor can access during development

Whether production data may be copied into test environments

How secrets, API keys, and credentials are stored

Whether audit logs are required

How incidents are reported

Whether a security review or penetration test is part of the scope

This is also where you should agree on hosting responsibility. If the vendor deploys to your cloud account, make sure access can be removed cleanly. If the vendor hosts the application, ask what happens if you later move it elsewhere.

Do not forget maintenance and handover

The first release is not the end of the software. Browsers change, APIs break, dependencies need patches, and users find rough edges once the system handles real work.

Decide before launch what support looks like:

Warranty period for defects found after release

Response times for urgent issues

Monthly maintenance budget

Ownership of monitoring and backups

Handover documentation and training

Exit plan if you change vendors later

A good contract makes the exit boring. You should be able to leave with source code, documentation, deployment instructions, credentials, and enough knowledge to keep the software alive.

Contract red flags when hiring a software team

Be careful if a proposal or contract has any of these problems:

The vendor will not define acceptance criteria

The contract says the vendor owns all code forever

There is no change request process

Payment is almost entirely upfront

Support after launch is not mentioned

Security and data processing are treated as "standard" but never described

The timeline assumes instant feedback from every stakeholder

None of these automatically means the vendor is bad. They do mean you need to slow down and ask direct questions.

A simple pre-signing checklist

Before you sign a custom software development contract, make sure you can answer yes to these questions:

Can we explain the scope without using vague product labels?

Do we know what is included and excluded from version one?

Are deliverables tied to acceptance criteria?

Do we know who owns the code and when access is transferred?

Are payment milestones connected to real progress?

Is there a written change request process?

Are GDPR, security, hosting, and data access covered?

Is maintenance or warranty support defined?

Do we have a handover plan if the relationship ends?

If any answer is no, fix it before signing. The awkward conversation is cheaper now than after the budget is spent.

Where Syntanea fits

At Syntanea, we build custom software, AI automation, and internal tools for companies that want practical systems rather than vague transformation slides. We are based in Wrocław, Poland, and we work with European clients who care about clear scope, direct communication, and maintainable code.

If you are still shaping the project, start with our guide to the software development discovery phase. If you are comparing budgets, read custom software development cost in Europe. If you need help turning a rough idea into a contract-ready scope, send us a note.

Frequently asked questions

What should be in a custom software development contract?

A good contract covers scope, deliverables, acceptance criteria, payment milestones, IP ownership, change requests, security, data handling, maintenance, and handover. The exact legal wording depends on your jurisdiction, but those business points should not be missing.

Who owns the source code in custom software development?

Usually the client owns newly written source code after the agreed invoices are paid. The contract should still separate project-specific code from the vendor's pre-existing libraries, open source components, and general know-how.

Should custom software be fixed price or time and materials?

Fixed price can work when the scope is stable and acceptance criteria are clear. Time and materials can work when the product needs iteration. Many projects use a hybrid model: fixed discovery or milestones, then transparent hourly work for changes.

How do change requests work in software projects?

The safest process is written approval before extra work starts. The vendor describes the change, estimates cost and timeline impact, and waits for an approved decision from the client-side owner.

Do I need a lawyer for a software development contract?

For a serious business system, yes. This checklist helps you catch practical project risks, but a lawyer should review liability, IP, data processing, jurisdiction, and termination terms before you sign.

Custom software development contract checklist before you sign