ITdoc

DOCUMENTS / IT / SOFTWARE

Software DevelopmentAgreement.

More than a specification,
deadline, and price.

A software development agreement should describe not just what is to be created, but the relationship between the client and the developer: the development process, changes to requirements, acceptance of deliverables, intellectual property rights, use of third-party components, and the consequences of departing from the agreed course.

[ MAIN SCENARIO / DEVIATIONS ]
01[ THE REAL CHALLENGE ]

Development rarely
goes exactly to plan.

At the start of a project, the parties may have a clear understanding of the overall outcome without yet knowing every detail of the future product.

  • Requirements change.
  • New tasks emerge.
  • Timelines change.
  • Third-party components are used.
  • Questions arise about the deliverables.

A good development agreement should therefore address not just the ideal scenario, but also changes during the project.

02[ WHAT TO CONSIDER ]

What needs to be defined.

  1. 01

    What is being created

    The product, module, functionality, code, documentation, and other deliverables.

  2. 02

    How requirements are defined

    What is agreed before work starts and how requirements may change.

  3. 03

    How development is organised

    Stages, interaction between the parties, and dependencies between them.

  4. 04

    How deliverables are accepted

    Acceptance criteria, review periods, and handling comments and issues.

  5. 05

    Who owns the rights

    When rights arise or are transferred, and the scope of the rights transferred.

  6. 06

    Which components may be used

    Open source, third-party libraries, APIs, and other external elements.

  7. 07

    What happens when things change

    Change requests, additional work, and adjustments to timelines and fees.

  8. 08

    What happens after launch

    Support, bug fixes, updates, and further development.

03[ MODELS ]

One document cannot
fit every development model.

M.01

FIXED SCOPE

A predefined outcome and scope of work.

M.02

TIME & MATERIALS

Payment for time and resources actually used.

M.03

DEDICATED TEAM

A team provided to work on the product.

M.04

MILESTONES

Development and acceptance in separate stages.

M.05

HYBRID MODEL

A combination of approaches.

The agreement's structure depends on the development model.

04[ INTELLECTUAL PROPERTY ]

The code is written.
But who owns it?

Payment for development should not, by itself, be treated as settling the question of intellectual property rights.

The agreement must define the legal status of the deliverables and how rights are granted or assigned, taking into account the chosen relationship model.

Intellectual Property
DEVELOPER
CREATES
CODE
RIGHTS
CLIENT / LICENCE / OTHER MODEL
05[ THIRD-PARTY COMPONENTS ]

Your product may contain
more than your own code.

Modern software typically uses libraries, frameworks, open-source components, APIs, and other third-party technologies.

The contractual model must address their possible use and the restrictions imposed by the relevant licences and terms.

PRODUCT
  • OWN CODE
  • OPEN SOURCE
  • API
  • LIBRARIES
  • THIRD-PARTY SERVICES
06[ SERVICES ]

What we can do.

  • 01draft an agreement for the specific development model
  • 02review the client’s or developer’s agreement
  • 03define the intellectual property rights model
  • 04design a process for changing requirements
  • 05establish acceptance procedures
  • 06allocate the risks of using third-party components
  • 07align the main agreement with the specification and schedules
  • 08adapt the agreement for cross-border development
  • 09negotiate the agreement
08[ RELATED PRACTICES ]

Related practices.

05IT & Technology02Contracts03Intellectual Property07International Business

[ SOFTWARE DEVELOPMENT AGREEMENT / DISCUSS YOUR DOCUMENT ]

Need an agreement
that fits how you work?
Let’s work through
how the relationship operates.