App Development Canberra: Commissioning an App for ACT Government, Research and Local Business

A practical guide to app development in Canberra: ACT procurement, Privacy Act and WCAG basics, and how to brief a build for government, research or…

If you are looking into app development in Canberra, the honest short answer is this: the build itself looks much like anywhere else in Australia, but the buyer around it often doesn't. A lot of Canberra apps are commissioned by, sold to, or used alongside government, universities and research groups, so procurement rules, privacy obligations and accessibility standards show up in the first meeting rather than at launch. Work out who your buyer is, which of those rules actually apply to you, and write them into the brief before anyone quotes.

This guide is for Canberra business owners, not-for-profit managers, research teams and government suppliers who are weighing up an app. It covers who tends to commission apps in the ACT, how the ACT Government says it goes to market, what the Privacy Act and WCAG mean for a typical app, and how to brief app developers in Canberra or elsewhere so the quote you get back is one you can compare.

One disclosure up front: Adaptive Media is based in Burleigh Heads, Queensland, and works with clients Australia-wide. We do not have a Canberra office. If an in-person team in the ACT matters to your project, that is a fair reason to choose someone else, and we say more about that trade-off below.

App development in Canberra: the short answer

Most app projects in the ACT fall into one of three shapes:

• An app you will sell or supply to government. Your product or service is aimed at an ACT directorate, a federal agency, or a prime contractor working for one. The app has to survive their procurement process as well as their users.
• An app your organisation uses internally. Field inspection tools, booking and rostering apps, case or volunteer management, research data collection. The users are your staff, contractors or researchers.
• An app your customers or members use. A booking app for a clinic, a member portal for an association, a loyalty or ordering app for a hospitality group, a client app for a professional services firm.

The technology decisions in all three are similar. Our Flutter app development guide and custom app development in 2026 cover those choices in detail, so we won't repeat them here.

What changes in Canberra is the weight of the non-technical requirements. If your buyer is a public body, or your app handles personal information for an organisation covered by the Privacy Act, you will be asked about it early. The rest of this guide is about getting those answers right before the build starts.

Who actually commissions apps in the ACT

It helps to be specific about who is paying and who is using, because they are often different people.

Government suppliers and consultancies. A consultancy or services firm wins work with an agency and needs an app as part of delivering it, or wants to turn a repeatable service into a product. Here the client is the agency, but the commissioning party is the supplier. The supplier carries the delivery risk, so they need a developer who understands that the agency's requirements flow down into the app contract.

Research groups and university teams. A project needs a data collection app, a participant-facing tool, or a demonstrator for a grant. The users may be a few hundred participants or a handful of field staff. The constraints are usually ethics approvals, data storage rules set by the institution, and a fixed funding window.

Not-for-profits and associations. Member portals, event and volunteer apps, service-delivery tools for clients. Budgets are usually tight, the organisation may handle sensitive information about vulnerable people, and the board wants to know the app will still work when the original project lead moves on.

Private businesses. Health and allied health practices, trades and property services, hospitality, professional services, retailers. These buyers look most like the clients we see in other cities: they want a customer app or a staff tool that saves time and makes money.

If your buyer is the ACT Government: how the Territory goes to market

If you plan to sell an app, or app development services, to an ACT Government directorate, start with Procurement ACT rather than with a developer. Procurement ACT's Ways to supply page (read 11 October 2026) explains how the Territory approaches the market. A few points from that page are worth knowing before you scope anything:

• The Territory says it uses different sourcing methods "commensurate to the scale, scope and risk of a procurement", and that the quotation and tender thresholds are set out in the Government Procurement Regulation 2007.
• For goods or services not related to construction, the page says procurements of at least $25,000 but less than $500,000 require the Territory entity to seek at least three written quotations, or one written quotation from a supplier that is a certified Aboriginal or Torres Strait Islander entity, or a small or medium business based in the ACT or surrounding region.
• At $500,000 and above (non-construction), the page says the entity must run an open tender, and that all open tenders are advertised on the Tenders ACT website.
• The ACT Government also uses panels, multi-use lists and schemes for things it buys regularly. Procurement ACT notes that being on a panel "does not guarantee supplier work".
• Unsolicited proposals are possible, but the page says they must follow the Territory's published guidance.

The Procurement ACT home page (read 11 October 2026) also notes that the Government Procurement (Charter of Procurement Values) Direction 2020 commenced on 9 September 2020 and applies to all new procurements regardless of dollar value, and that the Territory considers ethical, environmental, economic and social factors in its procurement processes.

What this means for an app project, in practical terms:

1. Know which lane you are in. A small pilot, a limited tender and an open tender are very different sales processes. Your app's scope, and your pricing, should fit the lane the buyer is actually using. Ask them.
2. Do not assume the rules. The thresholds above come from one Procurement ACT page on one date. Procurement ACT's site also lists a Government Procurement Amendment Act 2026 and a procurement reform program, so check the current pages yourself before relying on any figure, and read the tender documents for each opportunity.

None of this applies if you are a private business building an app for your own customers. It only matters if an ACT public body is the one paying.

If your buyer is a federal agency or a prime contractor

Canberra is home to a large share of Commonwealth agencies, and many local suppliers sell to them directly or as subcontractors. Federal agencies have their own buying arrangements and security and design frameworks, and these are separate from the ACT Government's. We were not able to load the federal procurement and cyber security pages we wanted to cite when we checked them for this article, so we are not going to summarise them from memory.

Our practical advice instead:

• Ask the agency, or the prime contractor, to name the frameworks in writing. Which buying arrangement is the work coming through? Which security controls and assessments apply to this system? Which design or accessibility standard will the app be tested against? Is data allowed to sit outside Australia?
• Get those answers into the statement of work. If they are only in an email, they will be forgotten by the time the app is in testing.
• Flow requirements down honestly. If you are a prime contractor engaging an app developer, pass the relevant clauses on to them and ask how they will meet each one. A developer who says "yes, all of it" without questions has probably not read them.

If you are a business that does not sell to government, you can skip this section. Federal security frameworks are useful reading for anyone, but they are not automatically a legal requirement for a private business app.

Privacy is a design input, not a policy page

Whether you are building for government or not, the most common Canberra conversation we expect is about personal information. Health providers, not-for-profits working with vulnerable people, research projects and government suppliers all handle data that matters to the people it describes.

The Office of the Australian Information Commissioner (OAIC) explains, on its Privacy Act page (read 11 October 2026), that the Privacy Act 1988 regulates how Australian Government agencies and organisations with an annual turnover of more than $3 million, and some other organisations, handle personal information. The OAIC says the Act includes 13 Australian Privacy Principles (APPs), which apply to some private sector organisations as well as most Australian Government agencies.

The OAIC's Australian Privacy Principles page (read 11 October 2026) describes the APPs as covering the collection, use and disclosure of personal information, governance and accountability, the integrity and correction of personal information, and individuals' rights to access their information. It also says the APPs are principles-based and technology neutral.

Its page on the Notifiable Data Breaches scheme (read 11 October 2026) says that any organisation or agency covered by the Privacy Act must notify affected individuals and the OAIC when a data breach is likely to result in serious harm to an individual whose personal information is involved. The examples it gives include a lost device with customer information, a hacked database, and personal information sent to the wrong person.

Whether the Act covers your organisation is a question for your own legal adviser, especially given the "some other organisations" wording. But for app design, the practical steps are the same either way:

• Collect less. Every field in a sign-up form is a field you have to protect. Ask "what do we actually use this for?" for each one.
• Know where data lives. Ask your developer to list every place personal information will be stored or processed, including analytics, crash reporting, email services and AI features. Third-party tools are where surprises usually hide.
• Write a breach plan before launch. Who gets called, who decides whether it is notifiable, and who talks to users. The OAIC's breach pages also point to advice from the Australian Cyber Security Centre on preventing data breaches.

If your app uses AI to summarise, classify or recommend anything about people, the governance questions get sharper. Our article on AI governance in Australia covers how boards and leaders set guardrails for that.

Accessibility: write WCAG into the brief

Accessibility is another topic that comes up early when public bodies, universities and community organisations are involved, because their users include everyone. It is also simply good practice for any app.

The W3C's WCAG 2 Overview (read 11 October 2026) explains that the Web Content Accessibility Guidelines are an international standard for making web content more accessible to people with disabilities. Several points from that page are directly relevant to app projects:

• WCAG 2.2 has 13 guidelines organised under four principles: perceivable, operable, understandable and robust.
• Each guideline has testable success criteria at three levels: A, AA and AAA. Conformance is measured against those success criteria.
• WCAG applies to web content, including web on mobile. The W3C says it can also be applied to non-web technologies, such as native apps and software, as described in its WCAG2ICT guidance.
• WCAG 2.2 was published on 5 October 2023. The W3C says content that conforms to WCAG 2.2 also conforms to 2.1 and 2.0, and encourages using the latest version.

What to do with that:

1. Name the version and level in the brief. "Accessible" is not a requirement anyone can test. "WCAG 2.2 Level AA for the web app, with WCAG2ICT applied to the native app" is. If a government buyer specifies a different target, use theirs.
2. Test with assistive technology, not only automated tools. Automated checkers catch some issues. Screen readers, keyboard-only use, text resizing and colour contrast need a person to check.
3. Budget for it. Accessibility built in from the design stage is far cheaper than retrofitting. Ask your developer how they will test it and what they will hand over as evidence.

Universities, research groups and grant-funded apps

Research and university apps have their own rhythm, and it is worth planning for it.

The institution's rules come first. Ethics approvals, data storage requirements and IT security reviews are set by the institution, not by the developer. Get the relevant contacts into the project early. A developer cannot design around a requirement nobody told them about.

Field conditions are real. Research in regional areas or outdoors means patchy connectivity. Offline-first design, careful sync and conflict handling are often the hardest part of the build. If that is you, our Android app development guide talks through device testing, which matters even more when staff use whatever phones they have.

Canberra businesses and not-for-profits: customer, staff and member apps

Not every Canberra app is about government. Plenty of local operators simply want to serve customers better or stop running the business on spreadsheets. For these projects, the privacy and accessibility points above still apply, and you should be ready to explain clearly to customers how their data is handled.

The app types we would expect to see most often:

• Customer apps. Bookings, account management, ordering, loyalty, client portals. The test is whether customers actually use it more than once. Start with the one task they repeat most.
• Staff and field tools. Job sheets, inspections, check-ins, timesheets, photo capture, asset tracking. These often pay back faster than customer apps, because you can measure the hours saved.
• Member and volunteer portals. Renewals, event registration, resources, rostering. For not-for-profits, the key questions are cost to run, ease of handover, and whether non-technical staff can manage content.

Local team or remote team: what matters for a Canberra project

Searching for app developers in Canberra will give you a mix of locally based studios and national firms. Both can work. The question is what your project actually needs.

When a Canberra-based team is worth prioritising:

• Your buyer requires on-site work, in-person workshops or physical access to secure facilities.
• The contract or buyer requires specific personnel arrangements that a local team already holds.
• Your users are hard to reach remotely and you want the team doing frequent in-person research with them.

If none of those apply, a remote team is usually fine, provided they run clear video workshops, share working builds often and write decisions down. Choose on relevant experience and how they answer the privacy and accessibility questions in your brief.

If you want to compare how we approach app work in other cities, see our pages on app development in Sydney, app development in Melbourne and app developers in Brisbane. The process is the same; the local context changes.

A brief you can send this week

You do not need a long specification to get useful quotes. A two-page brief that answers these questions will get you further than a vague idea and a deadline:

1. Who is paying, and who is using? Name the buyer (your business, a research team, an ACT directorate, a federal agency, a prime contractor) and the users.
2. What problem does it solve? One or two sentences, plus how you will measure success.
3. The first version. The three to five tasks the first release must do well. Everything else goes on a later list.
4. Platforms. iPhone, Android, web, or a combination, and why.
5. Data. What personal information will the app collect, where must it be stored, and who needs access.
6. Rules that apply. Privacy obligations, the accessibility standard and level, and any buyer-specified security, procurement or contract requirements. If you are unsure which apply, say so and ask the developer to flag what they think is relevant.

Send the same brief to every developer you are considering. If one of them comes back with sharp questions about items 5 and 6, that is a good sign.

Where Adaptive Media fits

Adaptive Media designs and builds custom apps and AI systems for Australian businesses. We are based in Burleigh Heads, Queensland, work Australia-wide, and run projects remotely with clients in other states. We do not have a Canberra office, and we will tell you if we think your project needs a local or specially credentialed team.

You can read more about our approach to mobile app development, or get in touch with your brief, even a rough one. We will tell you what we would build first, what we would leave out, and which requirements we think need checking with your buyer.

Frequently asked questions

Do I need a Canberra-based developer to sell an app to the ACT Government?

Not necessarily. Procurement ACT's Ways to supply page (read 11 October 2026) describes the quotation and tender process, and notes that for some limited tender procurements, one of the routes is a written quotation from a small or medium business based in the ACT or surrounding region. Whether a local developer helps your bid depends on the opportunity, so read the tender documents and ask the buyer.

Does the Privacy Act apply to my small Canberra business app?

It depends. The OAIC says the Privacy Act covers Australian Government agencies, organisations with annual turnover of more than $3 million, and some other organisations. If you are not sure whether you are one of those other organisations, get advice. Either way, collecting less data and protecting what you collect is good practice.

Which accessibility standard should our app meet?

If your buyer specifies one, use theirs. Otherwise, many organisations choose WCAG 2.2 Level AA as a target. The W3C says WCAG can also be applied to native apps through its WCAG2ICT guidance. Put the version and level in your brief so it can be tested.