Can we treat New Zealand as part of an Australian build?

Commercially teams often do; technically it is two countries. Different currency, different tax rate and rules, different business register, different privacy statute. Sharing a codebase is fine - sharing a configuration is where the errors come from, and the tax one is the expensive kind.

What does the cross-border rule actually require?

That before personal information goes to someone overseas, you have reasonable grounds to believe it will be protected comparably. Using an offshore provider is not prohibited - assuming it is fine without checking is. In practice it means your sub-processors and their locations are a maintained record rather than an assumption.

Is the tax really that much simpler?

Yes, and it is a genuine relief after Europe or the US. One rate, applied very broadly, with very few exemptions or reduced categories. Most of the conditional logic other countries need simply is not required - which is worth knowing so nobody builds it defensively.

Does latency matter as much as it does for Australia?

More, if anything, because there are fewer nearby hosting options. The same rule applies - a chatty request pattern compounds the round trip - and the answer is usually to serve from the closest available region and to reduce the number of round trips rather than to optimise each one.

Laravel in New Zealand

Laravel development services for New Zealand businesses

New Zealand has one of the simplest tax systems to model and a demanding rule about sending data offshore. For a team in Türkiye building for Auckland, the second is the interesting half.

Updated September 22, 2026

New Zealand is frequently bundled into an Australian project and mostly survives it. The two places where it does not are tax, where the difference is a wrong number on every invoice, and privacy, where the rule about sending data overseas is directly relevant to a development team working from another country.

The offshore rule is about us as much as about you

New Zealand's privacy law restricts disclosing personal information to someone outside the country unless there are reasonable grounds to believe it will be protected comparably to the domestic standard.

That covers cloud providers, and it covers a development agency with access to production data. It does not prohibit either - it requires that the position be established rather than assumed.

In practice it produces three artefacts, and they are cheap when they are maintained and awkward when they are assembled under pressure:

A list of who holds the data. Hosting, email, error tracking, backups, analytics if any - with locations. Maintained as a record, not reconstructed when a customer asks.

A reason each one is acceptable. Contractual commitments, or a regime the receiving country operates. Written down in a sentence per provider.

A way to work without production data. The cleanest answer to the whole question is that developers do not need the real rows. Anonymised subsets and seeded factories make it true rather than aspirational, and they make the conversation with a prospective customer short.

We work from Ankara, so we are the offshore party in this arrangement. We would rather raise that at scoping than have it raised in a security review.

The tax is the easy part, genuinely

One rate, applied to almost everything, with an unusually short list of exceptions. Compared with per-jurisdiction US sales tax or European reduced categories, the modelling is trivial.

The value of saying so is that teams build conditional tax logic defensively, out of habit from other markets, and then maintain it forever. If New Zealand is your only market, the tax model is a rate and a flag.

The thing that does need care is imported goods below the value threshold, where the obligation can sit with the seller rather than at the border. That is a rule about who collects rather than how much, and it is a decision to confirm before launch rather than after the first return.

Identifiers, addresses and the small things

New Zealand businesses have a public register and a number, which is worth validating at signup for the same reason it is anywhere - a typed identifier is a guess until something checks it.

Addresses do not have a postcode-driven structure that maps neatly onto forms designed for the UK or the US, and there is no state or province layer. A form that requires one produces junk data, and a validation rule copied from another market rejects valid addresses.

Dates are day-first and the currency is not the Australian dollar. Both of those sound too obvious to mention and both appear in production regularly, because the configuration was copied from the Australian environment.

Latency, with fewer options

Auckland is further from most hosting regions than Sydney and has fewer choices nearby. The practical approach is the same: pick the closest region available, then reduce the number of round trips an interactive page makes rather than trying to make each one faster. A page that issues one request tolerates the distance; a page that issues twelve does not.

Working with us

We work remotely from Ankara. The overlap with New Zealand hours is very small, so the engagement is asynchronous by design - written updates, reviewable pull requests, and a scheduled call rather than an expectation of availability.

The engineering is our usual application development and database work. What New Zealand adds is that the offshore question has to be answered properly, and that the tax model should be as simple as the law actually is.

Latency with fewer options makes caching the first reflex, and it is the one we spend most time undoing. A cache in front of a slow query usually makes the page slower, and the distance to the nearest region was not the reason it was slow.

Invoicing and payment. In US dollars, by bank transfer to an IBAN. The invoice is issued in Türkiye by Codefacture Yazılım A.Ş. and carries no Turkish VAT, since exported services are exempt. We are not registered for GST in New Zealand.