Custom Software Development in New Zealand
Automation connects the tools you already have. Software development builds the product itself.
There is a line between the two things AUXA does, and it is worth drawing clearly.
Automation connects tools a business already has. A workflow moves data between a form, a CRM and an accounting system. Nothing new is built; existing things are wired together. That work is described on our automation services page.
Software development builds the product itself. When no existing tool does the job, or when the job is the business, the answer is a system of its own: a data model, an interface, a permission structure, a release process. That is this page.
Most agencies offering both treat the second as an extension of the first. It is not. A workflow that breaks is an inconvenience; a platform that breaks is an outage for everyone using it, and the engineering discipline that difference demands is the thing being bought.
What we build
Multi-tenant SaaS platforms. One codebase serving many organisations, each seeing only its own data. The tenancy model is the first architectural decision and the hardest one to change later.
Internal systems that became products. A tool built for one organisation, reworked so it can be sold to others. The gap between those two things is mostly isolation, permissions and onboarding.
Compliance and regulated-industry software. Systems where an audit trail is a feature rather than a log file, and where who saw what and when has to be answerable.
Clinical and health-adjacent tooling. Software handling sensitive information, where data handling is a design constraint from the first commit rather than a review at the end.
Platforms AUXA has built
Three, all built in-house rather than for a client. They are the evidence for this service line, and each has its own page describing what it does and how it is put together.
AskHR360 — a multi-tenant HR and Health & Safety compliance platform.
VisaFlow — compliance software for immigration advisers.
ZenithMed AI — an ambient clinical AI scribe.
Building our own products rather than only client work means the architectural decisions on those pages are ours to explain, including the ones we would make differently now.
How the work runs
Architecture first, and written down. Tenancy model, data isolation, authentication and the release path are decided before feature work starts. Retrofitting any of them is a rewrite.
Shipped in slices. A narrow path working end to end beats a broad set of half-built screens, because only the first tells you whether the architecture holds.
You own it. The repository, the infrastructure and the deployment pipeline are yours. A platform you cannot deploy without us is a platform you do not own.
Handover is part of the build. Documentation and a working local environment for someone who was not there when it was written.
When custom software is the wrong answer
Often. If an off-the-shelf product does eighty per cent of what you need and the remaining twenty is preference rather than differentiation, buy the product and automate around it. Custom software earns its cost when the software is the thing you sell, when no product fits the regulatory shape of your industry, or when the workflow you depend on cannot be expressed in someone else’s tool.
If that is not your situation, we will say so.
Talk to us
AUXA builds custom software for New Zealand and Australian businesses. Start with contact, or read how we approach a build on our process page.
Frequently asked questions
Do you build for clients or only your own products?
Both. The three platforms described on this site were built in-house, which is why we can describe their architecture in detail. Client work is covered by the usual confidentiality.
What is the difference between your automation and software development services?
Automation connects systems a business already runs. Software development builds a system that did not exist. They use different engineering practices and are priced differently.
Do we own the code?
Yes. The repository, infrastructure and deployment pipeline are yours, and handover includes a working environment for a developer who was not involved in the build.
Can you take over an existing codebase?
Sometimes. It depends on the state of the code and whether the original architecture supports where you want to go. That assessment comes before any commitment.