Building Software in Australia: What the Privacy Act and ACL Actually Require of Your App

The Privacy Act 1988 sets national rules for how organisations collect, use, store and disclose personal information, and it covers most apps the moment they capture a user's name, email or behavioural data. The Act is built around a set of principles, known as the Australian Privacy Principles, that describe how personal information should be handled across its whole life in a business, from the moment it is collected through to when it is eventually deleted. "Personal information" is defined broadly. It is not limited to sensitive categories like health or financial records. A user's name, email address, IP address, or a record of how they used a feature can all count, depending on the context. Three obligations come up again and again in how this plays out for a piece of software: - Use data only for the purpose it was collected for. If a user signs up to use a booking feature, using that same data for an unrelated purpose later is a different matter under the Act, and generally needs its own basis. - Do not disclose personal information to a third party without an adequate basis, which usually means consent or a specific permitted exception. Sending user data to an external vendor, including some AI tools, can count as a disclosure. - Take reasonable steps to keep personal information secure, appropriate to the sensitivity of what is held and the size of the organisation holding it. None of this means every small app needs a compliance department. It does mean that a developer designing the data model, the third-party integrations and the storage approach is making decisions with legal weight attached, whether anyone names it that way during the build or not. This is general guidance only. Whether and how the Act applies to a specific business depends on facts a lawyer needs to assess, including turnover, industry and the type of data involved.

The Australian Consumer Law applies to software the same way it applies to any other product or service sold in Australia, not as a special add-on for tech. The ACL sets baseline consumer guarantees that generally apply when a business supplies goods or services to consumers, covering things like the product doing what it was reasonably expected to do and being fit for the purpose it was sold for. Software delivered as a service to a business or its customers is not automatically exempt from this just because it is intangible. The ACL also prohibits misleading or deceptive conduct in how a product or service is advertised and sold. For software, that touches marketing claims, pricing pages, feature lists and anything a sales conversation promises that the product does not actually do. A landing page that overstates what an app can do, or a pricing page that buries a material limitation, is the kind of thing the ACL is concerned with, independent of any contract terms written underneath it. The practical implication for anyone commissioning software is straightforward: the way a product is described to customers needs to match what it actually does, and that alignment is not just good marketing practice, it sits inside a body of law with real consequences attached. This is general information, not a substitute for advice on a specific product or campaign.

A software product built with these obligations in mind from day one is easier for a business customer to trust, and that trust is a genuine commercial asset, not just a compliance checkbox. Business buyers, particularly in regulated or client-facing industries, increasingly ask about data handling before they sign off on new software, even for a straightforward internal tool. Being able to say plainly where data is stored, who can access it, and what happens if something goes wrong is now a normal part of a sales conversation, not an unusual one. A developer who has built Australian products before, and who is accountable under Australian law themselves, can have that conversation directly and credibly. That is structurally difficult for a contractor working from overseas under a different legal system, who may never have been asked these questions before and has no local accountability if the answer turns out to be wrong. This is a genuine point of differentiation, not a scare tactic, and it is one that shows up in due diligence long before it shows up in a support ticket.

Any business commissioning custom software should be able to get clear answers to a short list of practical questions before the build starts, not after launch. - A privacy policy that actually matches what the app collects. A generic template pasted in at the end is a common gap, and it needs to reflect the real data flows in the product, not a guess. - Clarity on where user data is stored and who can access it, including any third-party services, analytics tools or AI features the app relies on. - A basic data breach response plan, even a simple one, so the business knows who does what if something goes wrong rather than working it out for the first time during an incident. - Marketing and pricing pages that describe the product accurately, reviewed against what the software actually does once it is built. - A clear point of contact for privacy and security questions, so the answer to a customer's question is never "we're not sure". None of these are exotic requirements. They are the kind of baseline any competent Australian-based development partner should be able to walk through as a normal part of scoping a project, not as an afterthought bolted on once a customer asks.

An offshore development team working purely from a written brief has little reason to know Australian privacy or consumer law exists, let alone how it applies to the product they are building. This is not a claim about the technical skill of offshore developers, who are often highly capable. It is a structural point: a contractor delivering a fixed scope of work from another jurisdiction is typically not thinking about Australian Privacy Principles or Australian Consumer Law obligations, because those laws are not part of their own operating environment and nobody on the project is asking them to be. The result is often a technically functional app that quietly carries gaps in its privacy policy alignment, its data handling design, or its marketing claims, none of which show up until a customer, a regulator, or an insurer asks a pointed question. By contrast, a developer building and operating inside Australia has an ordinary, everyday reason to keep these obligations in view, because the same law applies to their own business. That is the wedge worth asking about directly when comparing a local build against an offshore quote: not just the hourly rate, but who actually understands the legal environment the finished product has to live in.

13Labs builds custom software in Melbourne, under Australian law, with data handling and consumer-facing claims considered from the first scoping conversation, not bolted on after launch. buildAgency is a fixed-price development engagement with an Australian-based team you can actually reach, working to the same laws your business already operates under. See how it works at 13labs.au/buildAgency.

Does the Privacy Act apply to my small business app? It depends on factors like your turnover, industry and the type of data you handle, and the coverage of the small business exemption has been narrowing over time. Treat it as a live question rather than an assumption, and confirm your specific position with a lawyer rather than relying on general guidance like this. What counts as personal information under the Privacy Act? It is defined broadly and generally includes information that identifies a person or could reasonably identify them, which can extend to names, email addresses and some behavioural or usage data collected by an app. It is not limited to obviously sensitive categories like health records. Does the Australian Consumer Law apply to software-as-a-service, not just physical products? Broadly, yes. The ACL applies to services as well as goods, and software delivered as a service to Australian consumers or businesses is not automatically outside its scope just because it is delivered digitally. What is the single most common compliance gap in apps built by offshore teams? A privacy policy that does not actually match what the app collects and does, often because nobody on the build team was asked to think about it. It is usually a simple fix once someone reviews the real data flows against the stated policy, but it is commonly missed entirely rather than fixed badly. Should I get legal advice even for a simple internal tool? If the tool collects any personal information at all, it is worth a short conversation with a lawyer to confirm what applies to your situation, even for something that feels low-risk. A brief check early is generally far cheaper than resolving a gap after the tool is already in use across your business.