What you should actually get when a software build ends

A build ends in one of two ways. Either you finish the last invoice already holding everything you need — the code, the accounts, the ability to hand the whole thing to somebody else — or you finish it holding a login and a folder of files, and find out what is missing eighteen months later when you need to change something and the person who built it has moved on.

The second version is common, and it is rarely anybody’s bad faith. It happens because “handover” sounds like one event, and it is actually three, and it is entirely possible to complete one of them and none of the others.

Handover is three things, not one

Split it up before you check anything.

• Rights — who owns the copyright in the code. In Australia this is set by a clause in your contract, not by paying the invoice.
• Custody — whose name is on the GitHub organisation, the hosting team, the database project, the domain, the payment account. Mostly settled on day one, not at the end.
• Operability — whether a developer who has never seen the project can get it running from the repository and the documentation alone.

You can have any one of these without the others. A signed assignment of copyright does not get you into the deployment account. Every password in the world does not make you the owner of the code. And you can own the code, hold every account, and still have something no other developer can pick up, which in practice means you are still dependent on one person.

Layer one: the rights, and what the law does when your contract says nothing

Start with the thing most Australian buyers have backwards. There is no work-for-hire rule for software in Australia. Paying for code does not, on its own, make you its owner.

The Copyright Act 1968 (Cth) protects a computer program as a literary work under section 10(1). Section 35(2) vests copyright in the author — the person who wrote it. Section 35(6) shifts that to an employer, but only where the work was made under a contract of service, which means an employment relationship. An independent contractor works under a contract for services, so that section does not reach them. And the only commissioning exception in the Act, section 35(5), covers private photographs, portraits and engravings. There is nothing equivalent for code.

So paying the invoice, on its own, does not make you the owner. If your contract is silent, the developer owns the copyright and you hold something much weaker: an implied licence to use the software for the purpose that was contemplated when you engaged them. Australian courts have recognised that kind of licence for a long time, but it is narrow and purposive. It is not ownership, and it will not survive contact with an acquirer’s due diligence.

Two provisions fix it, and both need to be in the contract:

• Section 196(3) — an assignment of copyright “does not have effect unless it is in writing signed by or on behalf of the assignor”. Nothing has to be registered, filed, stamped or witnessed. There is no software copyright register in Australia. But it does have to be written and signed by the person giving it up.
• Section 197(1) — an agreement can assign future copyright, so that it vests in you as each file comes into existence. This is the clause worth asking for by name. Without it, your ownership depends on somebody signing a deed at the end of the project, which is exactly the moment a soured relationship makes that hard.

Moral rights cannot be waived here

A detail that trips up contracts copied from American templates. Moral rights — attribution, and the right not to have work subjected to derogatory treatment — belong personally to the human author. Section 195AN(3) says they are not transmissible by assignment. A company never has them, because a company is not an author.

They can only be dealt with by consent, and section 195AWA requires that consent to be written, genuinely given, and to specify the acts and the works it covers. A blanket “the author waives all moral rights” clause is not a mechanism the Act recognises. If a supplier is a company with subcontractors, consents need to be collected from each individual who wrote code, not just from the company.

One asymmetry worth knowing

Section 98(3) provides that a commissioned film defaults to the commissioner, in the absence of agreement to the contrary. That is the opposite of the rule for code. If your build included video — an explainer, onboarding clips, anything — two different default rules are running on the same deliverable at once.

Layer two: custody. Your business is the owner, the developer is a member

One rule covers the whole of this layer, and it is worth saying before the detail: for every account, your business is the owner and the developer is a member. Not a shared login. Not an account in the developer’s name that they promise to move later. Owner and member.

This costs nothing to get right at the start and is genuinely painful to fix at the end. GitHub Free for organisations includes unlimited private repositories, albeit with a limited feature set, so there is no version of this where the repository had to live somewhere else for budget reasons. Paid features can be added later; ownership cannot be added later without the other side’s cooperation.

The mechanics differ per platform, and the differences matter more than the generic advice suggests. What follows is for the stack we use; the principle transfers, the specifics will not.

Platform mechanics last checked 28 August 2026 against each vendor’s own documentation. These change; re-check before you rely on them.

The general shape holds across all of them: a transfer moves the thing itself and silently leaves behind the connective tissue — integrations, drains, monitoring, anything configured outside the project. Budget an hour after any transfer to find out what stopped working.

The domain is the one that actually hurts

Of everything on this page, the .au domain is the item most likely to be wrong at an Australian small business, and the most expensive to correct.

Under auDA’s .au Licensing Rules, the registrant must itself satisfy the Australian presence and eligibility criteria for the namespace, and must maintain that presence throughout the licence period. Where an agent registers a domain on someone’s behalf, the rules require the agent to ensure the actual person is recorded as the registrant. A developer or agency holding your domain in their own name is not simply a commercial inconvenience.

And correcting it is not a password handover. Changing the registrant is a formal transfer: the incoming registrant has to satisfy eligibility in its own right, enter a new licence agreement, and pay a new licence fee. If the relationship has already broken down, you are asking someone you are in dispute with to co-operate in a multi-step process.

Secrets get rotated, not transferred

A spreadsheet of passwords is not a handover artefact. Any credential the developer has seen should be treated as spent, because you cannot un-see a key. The deliverable is rotation, with a dated list of what was rotated.

For a typical build that means new database service keys, a new payment gateway restricted key and webhook signing secret, new LLM API keys, new transactional email keys, fresh OAuth client secrets, and new environment variables in every environment — not just production.

There is a live trap here for anything built on Supabase. The legacy anon and service_role keys are being deprecated by the end of 2026, and Supabase’s own guidance is to move to publishable and secret keys, which can be created and revoked individually. A project still running on the legacy keys cannot be cleanly re-secured after a handover without doing that migration first. Ask which key system your project uses before the final invoice, not after it.

The code you paid for that you will never own

An honest supplier tells you this before you ask. Every modern build sits on open-source libraries, and nobody can assign what they do not own. What you get is your own code, plus licences to the dependencies underneath it.

That distinction only bites when a licence carries conditions. Permissive licences — MIT, BSD, ISC, Apache-2.0 — require notices to be preserved, and Apache-2.0 adds NOTICE-file obligations. Reciprocal licences are the ones to know about: AGPL-3.0 in particular extends its source-provision obligation to people who interact with the software remotely over a network, which is exactly the shape of a hosted web application.

To be clear about the limits of that: this is licence text and mainstream practice, not settled Australian law. No Australian court has ruled on the enforceability or interpretation of open-source licences, and anyone who tells you otherwise is overstating it.

The artefact to ask for is a component inventory — every dependency with its licence identifier. The 2026 Minimum Elements for a Software Bill of Materials, published by CISA with the Australian Signals Directorate’s Australian Cyber Security Centre and international partners, now lists the component licence as a minimum data field. A supplier who cannot produce that list does not know what is inside your application either.

Your data is a deliverable too

What you want is a restorable database export plus the full migration history, in a documented format. Not a screenshot of an admin panel. Not a CSV of whichever tables somebody remembered.

The migrations matter more than the dump. Schema, row-level security policies and constraints usually live in migration files, so a dump without them is a pile of rows with no rules attached — it will load, and it will not enforce anything it used to enforce.

Then ask for a documented restore, performed once, in front of you. A backup nobody has ever restored is a hypothesis.

One caution if the system holds personal information — customer records, student records, anything about people under 18. Moving a production copy around during a handover is itself a handling of that information, and the fewer copies that exist on personal laptops and in shared drives afterwards, the better. Agree where the export goes and what happens to it once the restore is verified.

Layer three: can somebody else actually run it?

This is the layer nobody checks, and the one that decides whether you are actually free of your supplier.

The test is simple. Give a developer who has never touched the project a clean machine, the repository and the documentation, and nothing else. No phone call to the person who built it. Then require three outcomes:

• The application runs locally.
• The test suite runs.
• A trivial change deploys to a staging environment.

If they get there, you have a system. If they do not, you have a folder of files and a dependency on one person’s memory.

Run it while the original supplier is still under contract and still being paid. That is the only window in which an unpaid invoice will get whatever it finds fixed. A clean-machine test run a month after the final invoice tells you the same information with none of the power to act on it.

Working backwards from that test tells you what the documentation actually has to contain, roughly in order of how badly it hurts when missing: environment variables and where their values come from; local setup from a clean machine; how to deploy and how to roll back; the third-party accounts the system depends on and what each is for; the database schema and how to run migrations; and a short runbook for the things that break in the first month.

How we do it, including where our own default is weaker than it should be

Our stack is Next.js, Supabase and Vercel, with Stripe, Resend and the Claude API where a build needs them. The account list above is the actual list we work through, not a generic one.

The most complex handover surface we have built is the NDIS documentation platform we designed and built in-house — an AI-assisted tool that generates draft case notes, incident reports and progress notes and flags content for human review. It has multi-tenant authentication, role-based access, row-level security on every table, Stripe subscriptions kept in sync by webhooks, and a separate participant-facing subdomain. Every one of those is a handover item: the webhook signing secret, the row-level security policies living in migrations, the subdomain’s DNS, the API keys. That build is where most of this checklist comes from.

Now the part that argues against us. Our current default is that repositories live on our GitHub during the build and transfer to the client at handover. By the standard set out above — your business is the owner, the developer is a member — that is the weakest link in our own process, and the honest thing to say is that the better default is a client-owned organisation from the first commit. If you are engaging us, ask for that. If you are engaging anyone else, ask for it too.

One more honest qualification. PathMed and Skyhigh Academy, the two education platforms we have built, are both on ongoing maintenance arrangements, so accounts stay shared after go-live by design. That is a different situation from a clean exit, and it is worth being explicit about which one you are in. Shared access during a maintenance relationship is normal. Shared access with nobody maintaining anything is just an unresolved handover.

What not to ask for

Over-asking makes a negotiation worse, not safer. Four things buyers commonly demand that they usually should not.

Source code escrow

Escrow is a three-party arrangement for the case where the supplier keeps the code and you licence it, with release on defined triggers like insolvency or material breach. It does not transfer ownership. If you already own the repository in your own GitHub organisation, the repository is the escrow, and paying a third party to hold a copy of it is usually money for nothing. Escrow earns its keep in a narrow set of cases: the supplier retains the repo, the software is central to your operations, or you are licensing rather than owning.

A blanket assignment of everything

A supplier who agrees to assign every line they wrote, including the generic scaffolding they carry between projects, has either not read the clause or is not being straight with you. Reusable components are normal and they make your build cheaper. The clause you actually want separates background material, which is licensed to you, from project material, which is assigned to you. Demanding everything usually gets you a worse warranty rather than better rights.

A separately priced handover phase

If the accounts were in your name from day one, handover is an afternoon. A quoted handover package is often a bill for undoing a custody arrangement that should never have existed.

Cutting off all access on day one

If the supplier is still doing maintenance, the question is not whether they have access but what access, recorded where, and revoked when. Named accounts you can remove, rather than shared logins you cannot, is the whole of the answer.

The checklist to take to your supplier

Copy this into an email. A supplier who is doing it properly will answer every line without friction, and the ones who hesitate tell you something useful.

Rights

• Is there a written assignment of copyright, signed by the assignor?
• Does it cover future copyright as created, rather than relying on a deed at the end?
• Does it cover code, database schema, migrations, configuration and design files?
• Are there written moral rights consents from each individual who wrote code, specifying the acts and works?
• Is background material separated from project material, with a licence for the former?

Custody

• For each of the repository, hosting, database, registrar, registrant of record, DNS, sending domain, payments, LLM API and error monitoring — is my business the account owner, with the supplier as a removable member?
• Does a WHOIS lookup on the domain show my business as registrant?

Operability

• Has the clean-machine test been run and passed, while the supplier was still engaged?
• Does the test suite run? If there is no test suite, has that been stated plainly rather than left to be discovered?
• Are deploy and rollback documented?
• Has a database restore been performed once, in front of me?
• Is there a runbook for the first month?

Evidence

• A dependency list with licence identifiers.
• A dated list of every secret rotated at handover.
• A production data export, restored and verified.
• A named person to call, and for how long.

Common questions