How to Contract a Software Agency in Australia: What the Agreement Should Actually Say

Most founders read an agency contract the same way they read app terms and conditions – they scroll to the bottom and sign. The proposal looked good, the team seemed sharp, the price felt fair. The contract is just a formality. Until it isn’t.

We’ve seen founders finish a $120,000 build and discover they don’t own the IP outright. We’ve seen scope disputes that stalled projects for six weeks because the definition of “revision” was never pinned down. We’ve seen a founder try to move their codebase to a new agency and find out the original agency had licensed, not assigned, the intellectual property – and technically had a claim over the production system still running in market.

None of these founders were naive. They just didn’t know what to look for. So here’s what a software agency contract in Australia should actually say – and the specific clauses that protect you when things get complicated.

IP Assignment vs IP Licence: The Distinction That Actually Matters

This is the single most important clause in any software agreement, and it’s where we see the most dangerous ambiguity.

An assignment means the intellectual property – the code, the architecture, the designs – transfers to you on payment. You own it outright. You can take it anywhere, modify it, resell it, open-source it. The agency’s rights end.

A licence means the agency retains ownership but grants you the right to use the work under defined conditions. This sounds fine in practice – until you want to move to a new agency, open a new product line on top of the codebase, or raise a round and your investor’s lawyer starts asking questions.

Australian contract law doesn’t default to assignment just because you paid for the work. Employment law has different implications to contractor arrangements, and contractor-built IP doesn’t automatically transfer to the commissioning party. You need it written explicitly: “The Agency assigns all intellectual property rights in the Deliverables to the Client upon receipt of full payment.”

Watch for carve-outs. Most agencies reasonably retain IP in their pre-existing tools, frameworks, and reusable libraries – that’s fair. What you need is clarity on where their existing IP ends and your bespoke build begins, and a licence grant for any pre-existing components embedded in your product.

Scope Definition: Vague Language Is a Budget Risk

The scope of work section is where project disputes are born. Not in the actual build – in the sentence that said “the platform will support user management” without defining what “support” meant.

Good scope language is specific about what is included and silent about nothing important. It should describe:

• The specific features being built (user stories or feature descriptions, not just names)
• The platforms and environments being targeted (web only? iOS? specific browsers?)
• Integrations – named systems, not “third-party integrations as required”
• What is explicitly out of scope for this engagement
• The definition of “complete” – what state must the deliverable be in before payment is triggered

That last one matters enormously on fixed-price projects. “Complete” should mean deployed, tested against agreed acceptance criteria, and with documented handover – not “the agency thinks it’s done.” Acceptance criteria don’t need to be a 40-page spec. Even bullet-pointed functional requirements tied to payment milestones give you something concrete to point to.

If you’re signing a time-and-materials agreement, the scope section works differently – it defines the work order and budget ceiling, not a fixed deliverable. Make sure the contract specifies a budget cap that requires written approval to exceed. Without it, T&M engagements can drift quietly past your runway.

Payment Structure and What It Should Be Tied To

The standard agency payment structure in Australia runs roughly 30-40% upfront, with the remainder split across milestones or invoiced monthly. That’s reasonable. What matters is what the milestones are actually tied to.

Milestone payments should trigger on delivery and acceptance of something tangible – a working staging environment, a completed integration, a signed-off design system. Not on calendar dates. Not on “commencement of Phase 2.” Calendar-based billing on a fixed-price project means you’re paying for time, not outcomes, which defeats the point.

Also check: does the contract specify what happens to money paid if the agency fails to deliver? Most standard agreements are silent. You want a clause that either entitles you to a refund of milestone payments for undelivered work, or gives you the option to terminate and take what’s been built to date – with the IP that goes with it.

One more thing: GST. Make sure the contract specifies whether quoted amounts are inclusive or exclusive of GST. In a $150,000 engagement, an ambiguous GST clause is a $15,000 surprise.

Confidentiality, Data Handling and the Privacy Act

If you’re building anything that touches user data – which is most SaaS products – the contract needs to address data handling explicitly. This isn’t just legal hygiene; under the Australian Privacy Act 1988, obligations follow data, and you as the product owner are accountable for how your contractors handle personal information.

At minimum, the agreement should:

• Require the agency to treat all client business information as confidential during and after the engagement
• Specify that the agency will not access production data beyond what’s required for the build
• Prohibit the use of real user data in development or testing environments without explicit written approval
• Confirm that data is not shared with subcontractors without your consent – and if it is, that the subcontractors are bound by equivalent obligations

If you’re in health, fintech, or any regulated space, the bar is higher. You’ll likely need a data processing addendum that maps to your own compliance obligations. This is worth having your lawyer review – not because agencies are malicious, but because gaps in the chain of data handling agreements are exactly what regulators look for if something goes wrong.

Warranties, Liability Caps and What They Mean in Practice

Most agency contracts include a liability cap – typically limiting the agency’s total liability to the fees paid under the agreement. For a $90,000 build, that means if the agency ships something that causes you $500,000 in damages, you can recover $90,000 at most.

That’s industry standard and not unreasonable. But read what’s excluded from the cap. Fraud and gross negligence should not be capped. Confidentiality breaches sometimes carry their own liability threshold. If the agency is handling particularly sensitive data or building systems with significant operational risk, you may want to negotiate a higher cap or require them to hold professional indemnity insurance at a specified level – ask for a certificate of currency before you sign.

Warranties on software work typically cover defects discovered within a defined period after delivery – 30 to 90 days is common. Check what’s covered: bugs against the agreed spec, yes. Performance issues that emerged post-launch because you scaled to 10x the expected load, probably not. Be clear on the boundary.

What you should push back on: any clause that excludes liability for delays caused by the agency’s own resourcing decisions. If a project runs three months late because the agency underestimated the build and shuffled your team onto another client, that’s their problem, not a force majeure event.

Termination Rights and What Happens to the Build

This is the clause founders almost never read until they need it.

A well-drafted agreement gives both parties termination rights, but the key protections you need are on your side:

• Termination for convenience: You should be able to exit with reasonable notice (typically 10-30 days) and pay for work completed to that point – not the full project value
• Termination for cause: If the agency materially breaches the agreement – repeated missed milestones, shipping work that doesn’t meet spec, abandoning the project – you should be able to terminate immediately and receive a refund for undelivered milestones
• What you receive on termination: The contract must specify that all work in progress, code, assets, credentials and documentation are handed over to you within a defined timeframe – typically 5-10 business days

The handover clause is easy to overlook when you’re optimistic at the start of a project. Build in the detail anyway. Which repositories? Access to which infrastructure accounts? Design files in what format? A vague “all deliverables” clause creates negotiation on the way out when you’d rather be moving fast.

If you’re evaluating an agency now and want a second set of eyes on the commercial structure before you sign – or you’re starting from scratch and want to understand how we structure our own agreements – talk to Amora about your build. We’re happy to walk through the specifics before any commitment is on the table.

The contract isn’t the exciting part of building software. But it’s the part that determines whether the exciting part – the product you’re actually trying to ship – stays yours.