Software Development Contract Checklist: 12 Risks to Check Before You Sign

A Software Development Contract Checklist Can Prevent Expensive Problems Later

Software development contract checklist might not be the first phrase that comes to mind when you’re excited about getting a new system, app or digital product built. But before signing a development agreement, there are technology questions that deserve just as much attention as the price and delivery date.

A solicitor should review the legal terms. My concern as a technology consultant is slightly different.

I want to know whether the agreement and proposed delivery model leave your business in control of what it is paying for.

Who owns the code? Where will it be stored? Who controls the cloud accounts? How will you know that a milestone is actually complete? What happens if the developer disappears, the project runs late or you decide to move to another development team?

Those questions can expose technology risks that are easy to miss in a contract that otherwise looks perfectly reasonable.

I’ve spent decades working on software projects from both the technical and leadership sides. One lesson comes up repeatedly. A problem that takes ten minutes to discuss before signing can take months and a substantial amount of money to fix afterwards.

The principle is simple. People before technology. A good agreement should create clarity for the people funding, managing, building and eventually supporting the software.

Takeaways

1. Is the Software Development Scope Actually Clear?

One of the first things I look at is deceptively simple.

What exactly has the developer agreed to deliver?

“Develop a customer portal” is not a useful scope.

Neither is “build a mobile app with an administration system“.

Two sensible people can read those statements and imagine completely different products.

A useful scope should describe the important features, integrations, platforms, user types, interfaces and deliverables clearly enough that both sides can tell when the work has been completed.

For example, if you’re commissioning a mobile application, clarify:

• whether it covers iOS, Android or both
• whether a web administration portal is included
• what integrations are required
• whether data migration is included
• who provides designs and content
• whether reporting is included
• what documentation will be supplied
• whether deployment to app stores is included
• what isn’t included

You do not need a 400-page specification.

You do need enough detail to prevent two completely different interpretations of “finished”.

If the development proposal leaves large technical questions unanswered, an independent Technology Due Diligence review before signing can help identify assumptions that may later become costs.

2. Are Deliverables, Milestones and Payments Connected?

A project plan containing dates is useful.

A project plan where those dates are connected to measurable outcomes is much better.

I prefer milestones that describe an outcome rather than just the passage of time.

For example:

Weak milestone	Better milestone
Month 1 complete	Approved user authentication functionality completed and demonstrated
Development phase 2	Customer ordering workflow completed against agreed acceptance criteria
50% project completion	Specified features completed, tested and available in the agreed test environment
Final payment	Production release, documentation and agreed handover items completed

The contract should make it clear what triggers a payment.

This matters even more when a large percentage of the project cost is paid upfront.

You should also understand what happens when a milestone slips. Does payment still become due? Does the delivery date automatically move? How are dependencies on your team handled?

There is no universal payment model that suits every project.

The important thing is that payment, progress and responsibility make sense together.

3. Who Owns the Software and Intellectual Property?

This is one of the biggest issues to clarify.

Paying a developer to create software does not mean you should simply assume that you own every part of it.

Software may contain:

• custom code created specifically for you
• components the developer created previously
• commercially licensed libraries
• open-source software
• third-party APIs
• templates
• frameworks
• design assets
• code created by subcontractors

The agreement needs to distinguish these clearly.

The World Intellectual Property Organization provides useful guidance on intellectual property ownership in software development agreements, including assignment, background IP, licensing and third-party software.

Your lawyer should advise on the legal wording.

From the technology side, I want to know something more practical.

Will your business have the rights it needs to operate, change, maintain, transfer and commercially use the software?

If the answer is unclear, don’t leave it until launch.

4. Will You Have Access to the Source Code?

Owning intellectual property and having practical access to the software are related, but they are not the same thing.

Imagine discovering six months into a project that all your source code exists in a GitHub account controlled solely by the developer.

Or that you cannot deploy your own software without their help.

Or that nobody in your business has administrator access.

That’s an unnecessary business risk.

For important software, I generally want the business to have appropriate access to the source-code repository throughout development rather than receiving a ZIP file on the final day.

Depending on the project, you may also need access to:

• GitHub, GitLab or Bitbucket repositories
• cloud hosting
• databases
• domain names
• DNS
• application stores
• analytics platforms
• email services
• API accounts
• payment gateways
• third-party integrations
• backup systems
• deployment pipelines

The exact arrangement varies.

The principle doesn’t.

A critical part of your business should not depend entirely on one external person’s login details.

This is especially important if the software is central to your revenue or operations.

5. How Will You Decide Whether the Software Is Finished?

This is where acceptance criteria become important.

Acceptance criteria describe what must be true for a feature, milestone or product to be accepted.

Without them, disagreements become subjective.

The developer says, “It’s finished.“

The business says, “It doesn’t do what we expected.“

Both may genuinely believe they are right.

Good acceptance criteria could cover things such as:

• required functionality works
• specified integrations operate correctly
• supported browsers or devices have been tested
• agreed security requirements have been met
• critical defects have been resolved
• required documentation has been provided
• agreed performance requirements are achieved

You also need an acceptance process.

Who tests the software?

How long does the customer have to test it?

What happens when defects are discovered?

Which defects prevent acceptance?

What happens to minor defects?

These might feel like delivery details rather than contract issues. They become commercial issues very quickly when a payment depends on whether something is “complete”.

6. What Happens When the Requirements Change?

Requirements will change.

That isn’t automatically a sign of poor project management.

People learn as software takes shape. Customers provide feedback. Market conditions change. An integration turns out to work differently from what everybody expected.

The danger comes from having no agreed way to manage that change.

A sensible change process should answer:

1. Who can request a change?
2. Who estimates it?
3. How is the impact on cost assessed?
4. How is the impact on delivery assessed?
5. Who approves the change?
6. Does development continue while the decision is being made?

Without this, you risk scope creep, where small requests gradually increase the cost and timeline without anyone clearly deciding to expand the project.

Good Project Delivery isn’t about stopping change. It is about making change visible so the business can make informed choices.

7. Are Security Requirements Written Down?

“We build secure software” isn’t a security requirement.

You need to understand which security responsibilities belong to the developer and which belong to your business.

The requirements will depend heavily on the software.

A simple internal scheduling tool has a different risk profile from an application handling healthcare, financial or customer identity information.

Areas worth discussing include:

• authentication
• administrator access
• multi-factor authentication
• encryption
• audit logging
• backup and recovery
• vulnerability management
• dependency management
• secure development practices
• security testing
• incident notification
• access to production systems
• staff and subcontractor access
• handling of customer data

The OWASP Secure Software Contract Annex is a useful reference for thinking about security responsibilities within a software development relationship.

Australian organisations can also use the Australian Signals Directorate’s Essential Eight as part of the wider security conversation.

Do not blindly paste a long security framework into every contract.

Start with the actual business risk and decide what controls are appropriate.

8. Where Will Your Data Live and Who Controls It?

For business software, the code is only part of the asset.

The data can be far more important.

You should understand:

• what information the system stores
• where it is stored
• who can access it
• whether it leaves Australia
• whether subcontractors can access it
• how it is backed up
• how long backups are retained
• how data can be exported
• what happens to the data when the agreement ends

If personal information is involved, privacy obligations deserve specialist legal and privacy advice as well.

From a technology perspective, one question is particularly useful:

If you had to move to another supplier next month, could you get your data out in a usable format?

“We can export it” isn’t quite enough.

Export what?

In what format?

How long would it take?

What would it cost?

Could another developer understand and use it?

Those are much better questions.

9. Who Is Actually Going to Build the Software?

Sales meetings tend to feature experienced people.

Your project team may be different.

Before signing, understand:

• who will actually work on the project
• where they are located
• whether subcontractors are involved
• who the technical lead is
• who makes architecture decisions
• who your day-to-day contact will be
• what happens if a key developer leaves
• how knowledge is shared inside the development team

This is where my “people before technology” philosophy becomes very practical.

A brilliant technical design can still fail if the project depends on one person who understands everything.

Conversely, a team with good communication, documentation and shared knowledge can work through plenty of technical challenges.

Key-person dependency is a business risk.

Treat it like one.

10. What Documentation and Handover Will You Receive?

Documentation sometimes gets treated as optional paperwork.

Until the original developer isn’t there.

Then it suddenly becomes rather interesting.

The amount of documentation should match the complexity and importance of the system, but you may need:

• system architecture
• database structure
• API documentation
• deployment instructions
• infrastructure details
• administrator instructions
• backup procedures
• integration details
• third-party service details
• known issues
• development environment setup
• support procedures

Documentation should be useful enough for another competent technology professional to understand the system.

That does not mean documenting every line of code.

It means avoiding a situation where business knowledge exists only inside someone’s head.

A Technology Investment Readiness Review can also help businesses examine whether their technology, documentation, ownership and operational arrangements are strong enough before investment, acquisition or other major business events.

11. What Happens After the Software Goes Live?

Software doesn’t stop needing attention because somebody has declared the project finished.

Applications need support.

Dependencies need updates.

Operating systems change.

Browsers change.

Cloud platforms change.

Security vulnerabilities are discovered.

Users find unexpected ways to use things. Users are wonderfully creative like that.

Before signing, work out what happens after launch.

Ask:

• Is a warranty or defect period included?
• What counts as a defect rather than a new feature?
• How long is the warranty period?
• Who handles urgent production incidents?
• What support hours are available?
• Are response times defined?
• What is support charged at?
• Who performs updates?
• Who monitors backups and infrastructure?
• Is ongoing support optional or mandatory?

Also distinguish warranty, support and future development.

They are different things.

A fault in something already delivered isn’t the same as asking for a new capability six months later.

12. What Happens If You Want to Leave the Developer?

This is one of my favourite questions because it reveals so much about a technology arrangement:

Could another competent development team take over this software?

Not because you are planning to sack anyone.

A good business protects itself against possibilities.

Your supplier could close.

Your developer could leave the industry.

The relationship could deteriorate.

Your company could grow and need a different kind of technology partner.

Or the developer could simply win a bigger client and no longer have enough time for you.

An exit plan should consider:

• current source code
• repository access
• infrastructure access
• credentials
• data exports
• documentation
• open issues
• third-party accounts
• licence information
• knowledge transfer
• transition support

You should also understand any contractual termination obligations and have your lawyer review them.

The technology question is simpler.

Can the business keep operating if this relationship ends?

The 12-Point Software Development Contract Checklist

Before signing, I would want satisfactory answers to these 12 questions:

1. Scope: Is there a clear description of exactly what will be built?
2. Milestones: Are payments connected to measurable progress and deliverables?
3. Intellectual property: Are ownership and licensing arrangements clearly understood?
4. Source code: Will your business have suitable access to the code and repositories?
5. Acceptance: Is there an objective way to decide whether work is complete?
6. Changes: Is there a clear process for changes to cost, scope and timing?
7. Security: Are appropriate security responsibilities and requirements documented?
8. Data: Do you understand where your data lives and how you can retrieve it?
9. People: Do you know who will actually build the software and where the key-person risks lie?
10. Documentation: Will another competent team be able to understand and maintain the system?
11. Support: Is responsibility after launch clear?
12. Exit: Can you change development partners without putting the business at risk?

A legal contract review and a technology review solve different problems.

Your solicitor can advise whether the agreement protects you legally.

An independent technology adviser can examine whether the proposed delivery model, architecture, ownership, processes and practical arrangements make sense.

For a major software investment, I would rather find a problem before the signature than discover it halfway through development.

A Simple Red, Amber and Green Decision Framework

You don’t need to treat every concern as a deal breaker.

I often find a simple traffic-light approach useful.

Green

The issue is clearly documented and you understand the consequences.

Example:

Your business controls the Git repository and cloud environment, with the developer receiving the access they need.

Amber

The arrangement may be acceptable, but it creates a dependency or requires clarification.

Example:

The developer controls the repository during development but has a documented handover process and provides regular backups.

Ask more questions before accepting it.

Red

The arrangement creates a material risk and you cannot see a practical way to control it.

Example:

The developer owns the hosting account, repository and critical third-party accounts, refuses ongoing access and will provide source code only if the relationship ends.

That deserves attention before you sign.

A Technology Strategy should help the business maintain control of important technology decisions rather than simply handing them to whichever supplier happens to be building the system.

Common Mistakes I See Before Software Projects Begin

Choosing entirely on price

The cheapest quote can become very expensive if it excludes testing, documentation, deployment, project management or support.

Compare scope and risk, not just the number at the bottom of the proposal.

Assuming the developer will “take care of everything”

Someone still needs to represent the business.

Developers can recommend technical choices, but decisions about business priorities, risk and investment should stay with the organisation funding the project.

Leaving difficult discussions until later

Ownership, delays, changes, security, support and exit arrangements are easier to discuss before signing.

After a disagreement begins, everyone’s interpretation suddenly becomes much firmer.

Treating the contract and project plan as separate things

Your legal agreement, statement of work, delivery approach and technical arrangements should tell the same story.

If one promises fixed deliverables while another describes an open-ended Agile engagement, clarify which model you’re actually buying.

Depending on trust instead of visibility

Trust your development partner.

But also have access, reporting, documentation and governance.

Good controls aren’t an accusation. They protect both parties.

Frequently Asked Questions

What should I check before signing a software development contract?

Check the scope, deliverables, payment milestones, IP ownership, source-code access, acceptance criteria, change process, security, data control, documentation, support arrangements and exit plan. Your lawyer should review the legal terms, while a technology specialist can review the practical technology and delivery risks.

Who should own the source code for custom software?

There isn’t one arrangement suitable for every project. What matters is that you understand the ownership and licensing model and that your business has the rights and practical access it needs to operate, maintain, modify and transfer the software. Seek legal advice on intellectual property wording.

Should my company control the GitHub repository?

For business-critical custom software, having appropriate ongoing access to the repository usually reduces dependency on the developer. The exact ownership and access arrangement will depend on the project, but you should understand how you obtain the complete current source code if the relationship ends.

What are acceptance criteria in a software development contract?

Acceptance criteria define the conditions a deliverable must meet before it is considered complete. They can cover functionality, integrations, supported platforms, defects, performance, documentation and other agreed requirements.

Is a lawyer enough to review a software development contract?

A lawyer should advise on the legal agreement, rights, liabilities and obligations. A technology adviser looks at different questions, such as whether the proposed solution, delivery model, access arrangements, security, technical dependencies and handover plans make practical sense. For a material software investment, both perspectives can be valuable.

Before You Sign

A software development contract isn’t just paperwork between you and a supplier. It defines the foundations of what could become one of your business’s most important assets.

If you’re committing serious money to software and want an independent view before signing, my Technology Due Diligence service can examine the proposed technology, delivery model, risks and dependencies alongside your legal review.

Ten questions asked now are usually far easier to deal with than one nasty surprise six months into development. That is the real value of using a software development contract checklist before you commit.