Custom Software Development Sydney: Integration-First Builds for Multi-Site Businesses

Custom software development Sydney guide for multi-site firms: map your systems, set the system of record, plan integrations, SSO and NSW supplier basics.

Custom software development in Sydney is usually less about building something from nothing and more about building the piece that sits between systems a business already runs. For mid-market and multi-site organisations, that typically means an ERP, a CRM, a finance platform, an identity provider and often a data warehouse, plus a few legacy tools nobody wants to touch. The custom part is the workflow, portal or service that ties them together for head office and every site. Get that right by scoping integrations first, deciding which system owns each kind of data, and treating identity and audit as requirements from day one rather than extras.

This guide is for Sydney operations leaders, finance and IT managers, and founders of growing multi-location businesses who are weighing a custom build. It is organised around the systems you already have, not around a generic build process. If you sell to NSW Government, there is a section on the official supplier arrangements, with sources named and dated. Everything else is practical guidance from how integration-heavy software projects tend to go.

A quick note on who we are: Adaptive Media is based in Burleigh Heads, Queensland, and works with clients Australia-wide, including Sydney. We don't have a Sydney office. If you need a team physically in the room every week, weigh that honestly. If you are in Queensland, our Brisbane and Gold Coast custom software guides are written for those markets.

Custom software development in Sydney: where most projects really start

Most Sydney custom software briefs we would expect to see start with a sentence like one of these:

• "Our sites all do this differently, and head office can't see what's happening until month end."
• "We bought a good CRM and a good ERP, and our staff spend hours copying between them."
• "The off-the-shelf tool does 80% of what we need, and the other 20% lives in spreadsheets."
• "We acquired a business, and now we have two of everything."

None of those are really requests for a brand-new platform. They are requests for a layer of software that fits around existing systems: a staff portal, an operations dashboard, a quoting or job tool, a customer or partner portal, an approvals workflow, or a service that keeps data in sync.

That changes how you should approach the project. The first question isn't "what should we build?" It's "what do we already run, and what does each system do well?" Our national custom software development page covers what we build in general. This guide focuses on the integration-first approach that suits larger and multi-site Sydney organisations.

Map the systems you already run

Before anyone draws a screen, draw a map. It doesn't need to be pretty. A whiteboard photo or a simple diagram is fine. For each system, write down:

• What it is and who owns it. For example: the ERP, owned by finance; the CRM, owned by sales; the rostering tool, owned by operations.
• What data it holds. Customers, products, prices, jobs, staff, assets, invoices.
• How data gets in and out today. An API, a scheduled export, a manual upload, someone retyping it.
• Who uses it, and where. Head office only, every site, field staff, customers.
• Contract and change constraints. Licence terms, vendor support, planned replacements, systems you are already planning to retire.

Two things usually jump out of this exercise.

First, the real problem is often a handful of hand-offs rather than a missing system. The same customer gets created three times. A price changes in one place but not another. A job finishes on site, but finance doesn't hear about it for a week.

Second, some systems are on their way out. There is little point building tight integrations into a platform you plan to replace next year. Mark those clearly, and design so they can be swapped later.

This map becomes the most valuable part of your brief. A build partner who sees it can tell you quickly where custom software helps and where a configuration change or an existing connector would do the job instead.

Decide the system of record for each piece of data

Once you know what you run, decide which system is the source of truth for each type of data. This is the decision that most often goes wrong in integration projects, and it is cheap to fix on paper and expensive to fix in code.

A simple table helps:

The rules that follow from it are simple:

• Each field has one owner. Other systems can display or cache it, but they don't edit it.
• The custom software owns only what's genuinely new. Often that is a workflow or a record type that doesn't exist anywhere yet, such as site jobs, inspections, approvals or partner requests.
• Conflicts have a rule. If two systems disagree, everyone knows which one wins.

If your organisation can't agree on the owner of a piece of data, that is a business decision to make before the build, not something a developer should guess. Writing this table down early often saves more money than any technical choice later.

Integration patterns: APIs, events and file drops

With the map and the system of record table, the next question is how data moves. There are a few common patterns, and most real projects use more than one.

Direct API calls. The custom software asks another system for data, or sends it data, through that system's API. This is usually the cleanest option when the API is well documented and stable. Check the vendor's API limits, authentication method and versioning policy before you rely on it.

Events or webhooks. One system announces that something changed, such as "order created" or "job completed", and others react. This keeps systems loosely coupled, which helps when one of them is slow or down. It needs a plan for retries and for events that arrive twice or out of order.

Scheduled syncs. Data is copied on a timetable, such as every few minutes or overnight. This is simpler, but people need to understand that what they see may not be up to the minute.

File drops. A system exports a file, and another picks it up. It can feel old-fashioned, but it is sometimes the only option a legacy system offers. If you use files, define the format, naming, validation and what happens when a file is late or malformed.

For each integration in your map, a good partner should tell you which pattern they recommend and why, what happens when it fails, and how someone will know it failed. "It syncs automatically" is not enough. Ask how errors are logged, who is alerted, and how a failed record gets retried or fixed.

Identity, access and audit across sites

In a single-location small business, access control can be simple. In a Sydney organisation with several sites, business units or entities, it rarely is.

Single sign-on. If staff already sign in with a corporate identity provider, your custom software should use it. That means one less password, and when someone leaves, removing their access in one place removes it everywhere. Ask your partner which identity provider and sign-in standards they plan to support, and test it with real accounts early.

Roles that reflect how you actually work. A site manager may see their own site's jobs but not other sites. A regional manager may see several. Head office finance may see everything but change nothing operational. Write these roles down in plain language before the build. They are a business decision, not a developer default.

Separation between entities. If you run more than one legal entity or brand, decide whether staff can see across them, and whether data needs to be kept apart for contractual or privacy reasons.

Audit trails. For anything involving money, approvals, safety or customer records, record who changed what and when. Auditors, insurers and your own managers will ask. It is much easier to log changes from the start than to reconstruct history later.

Personal information. If the software handles personal information about customers or staff, work out with your adviser which privacy obligations apply, and design the software to collect only what you need, keep it secure, and let you find, correct or export a person's data.

If AI features are part of the plan, for example summarising records or classifying requests, our AI agency Sydney guide covers how to approach that responsibly.

Head office versus sites: rolling out across locations

Multi-site software has a particular failure mode: it is designed at head office, then dropped on sites that work differently. Staff quietly go back to spreadsheets, and the integration that looked good on paper ends up with half the data missing.

A few practices help:

• Bring a site into discovery. Spend real time with at least one site team, ideally two that work differently. Watch how they do the job now, including the workarounds.
• Design for the worst connection, not the best. Some sites, warehouses and vehicles have patchy connectivity. If staff need to use the software there, decide what must work offline and how it catches up.
• Pilot at one or two sites first. Run the new software alongside the old process for a defined period, fix what breaks, then roll out. Choose a pilot site that is representative, not just the most enthusiastic one.
• Plan the data migration per site. Each site may have its own spreadsheets and history. Decide what moves, what gets archived and what gets left behind.

The rollout plan belongs in the brief and the quote. If a proposal only covers "build and deploy", ask who will run the pilot, migration and training.

If your buyer is NSW Government

Some Sydney businesses build software they plan to sell to NSW Government agencies, or deliver custom software as a government supplier. If that is you, there are official arrangements you need to understand. None of what follows applies if you are building software only for your own business.

The ICT Services Scheme page on info.buy.nsw (read 13 October 2026; the page shows it was last updated 22 August 2025) describes the scheme as "a whole-of-government mandated arrangement for procuring ICT goods and services". Key points from that page:

• It is listed as scheme number SCM0020, mandatory, running from 29 January 2013 to 28 February 2029.
• It offers a list of prequalified suppliers across 18 categories. These include Category M (Systems and solutions), Category N (Software), Category Q (ERP and related corporate and shared services) and Category R (ICT Cloud Services). Within Category M, the page lists software support and maintenance services (M07) and testing services (M08).
• All ICT suppliers are eligible to apply for prequalification, subject to meeting the relevant requirements. To apply, you must first become a NSW Government registered supplier. The page describes an "always open" policy, so new suppliers can register at any time.
• Prequalified suppliers need to comply with the ICT Services Scheme rules.

The buy.nsw home page (read 13 October 2026) describes itself as the place where NSW Government buyers and suppliers connect, with a register of contract notices, open opportunities, and a Procurement Policy Framework covering requirements for each step of procurement.

Two other NSW policies may shape what an agency asks of your software:

• Cyber security. Digital NSW's cyber security policy page (read 13 October 2026) says the NSW Cyber Security Policy sets mandatory requirements that all NSW Government agencies must meet to manage risk to their information, systems and services. Those obligations sit with the agency, but expect the agency to ask suppliers how the software supports them.
• AI. Digital NSW's NSW AI Assessment Framework page (read 13 October 2026) says all NSW Government agencies must comply with the NSW AI Operational Policy and apply the AI Assessment Framework when required, under Circular DCS-2026-02. The page says the AIAF Platform became the mandatory platform for registering and assessing AI use cases across NSW Government from 30 September 2026. If your software includes AI features, expect agencies to work through this.

The practical advice is the same as for any government work: read the scheme rules and tender documents for each opportunity, ask the agency which requirements apply to your software, and get those requirements into the contract and the build plan.

Writing a brief a Sydney build partner can price

With the work above done, the brief nearly writes itself. A useful brief for integration-heavy custom software includes:

1. The problem and the measure. What is going wrong today, and how you'll know it's fixed: fewer manual re-entries, faster month-end, real-time site visibility, fewer errors.
2. Your system map. Systems, owners, data, current integrations, and anything you plan to retire.
3. The system of record table. Which system owns which data.
4. Integration expectations. For each connection, the preferred pattern if you have one, and how fresh the data needs to be.
5. Users, roles and sites. Who uses what, at which locations, with what permissions.
6. Identity and audit. Your identity provider, sign-in expectations, and what must be logged.
7. The first release. The smallest useful slice, often one workflow at one or two sites.
8. Rollout. Pilot sites, migration, training and support.
9. Constraints. Budget range if you have one, key dates, vendor contracts, and any government requirements if you sell to the public sector.
10. Ownership. Who owns the code, cloud accounts, integration credentials and documentation.

Send the same brief to every partner you're considering, so their answers are comparable.

Reading proposals: signals worth weighing

When proposals come back, look past the price and the portfolio. For integration work, these signals tell you more:

• They asked about your systems. Good partners ask detailed questions about APIs, data volumes, vendor limits and the system of record before they quote firmly.
• They named the risky integrations. Every project has one or two connections that are harder than they look. A partner who identifies them early is more trustworthy than one who says everything is straightforward.
• They explained failure handling. Logging, alerts, retries and a way to fix bad records.
• They proposed a first slice, not everything at once. One workflow, one or two sites, then expand.
• They were clear about ownership and handover. Your code, your cloud accounts, documentation someone else could follow.
• They told you what not to build. Sometimes an existing connector or a configuration change is enough. A partner willing to say so is looking after your budget.

If you also need mobile apps for staff or customers alongside the custom software, our Sydney app development page covers that side. And if you need senior technical leadership to oversee a vendor or a roadmap without hiring a full-time CTO, read about CTO as a service.

After go-live: running integrated software

Custom software that connects to other systems needs ongoing care, because those other systems keep changing.

• Monitor the integrations. Someone should see a failed sync before a site manager rings to complain. Agree what is monitored and who responds.
• Track vendor changes. ERP, CRM and identity vendors update their APIs and sometimes retire old versions. Build time into your support plan to keep up.
• Review roles and access regularly. People move between sites and roles. Make sure the permissions still match reality.
• Keep the system map current. When you add or retire a system, update the map and the system of record table.

Agree all of this in the support arrangement before launch, so it isn't a surprise later.

Where Adaptive Media fits

Adaptive Media designs and builds custom software, apps and AI systems for Australian businesses. We are based in Burleigh Heads, Queensland, and work with clients Australia-wide, including Sydney organisations, through remote workshops, shared documents and regular working builds. We don't have a Sydney office.

We are a good fit when you want integration-first scoping, a clear first slice, and software you fully own at the end. If you'd like a second opinion on your system map or brief, get in touch. We'll tell you where custom software helps, and where it doesn't.

Frequently asked questions

Should a Sydney organisation choose a Sydney-based software partner?

It depends on how much in-person time your project needs. Integration work is mostly done in discovery workshops, documentation and testing, which can work well remotely. If your stakeholders need regular face-to-face sessions, weigh that when choosing.

Do NSW Government procurement rules apply to our internal software?

No. Schemes such as the ICT Services Scheme govern how NSW Government agencies buy. They matter if you sell software or services to an agency, not if you build software for your own business.