Systems Integration in New Zealand

The demo is not the project

Every integration looks trivial when it is described. An order is created in one system, it appears in the other, everyone is pleased.

The budget goes on the days that are not like that:

• The record already exists, because someone entered it manually this morning.
• The connection drops after twenty of fifty records have transferred.
• A field that has been filled in for four years is suddenly empty.
• The other end rate-limits you at the exact moment you are busiest.
• Someone edits the same customer in both systems, differently, on the same afternoon.

A developer who asks about these in the first conversation is not overcomplicating things. They are the reason integrations either run for years or quietly corrupt your data for a month before anyone notices.

One-way and two-way are different projects

One-way is a pipe. Data flows from the system that owns it to the system that needs a copy, and if something fails you send it again. Most integrations should be this, and many that are specified as two-way do not need to be.

Two-way sync means both systems can change the same record, which means you need rules for who wins. That is not a technical detail — it is a business decision, and it is yours to make. If your accounts team fixes an address in Xero and a salesperson fixes it differently in the CRM, which is right?

Before asking for two-way, check whether one system could simply own each kind of data. That decision saves more money than any technology choice in the project.

Failure is the specification

Ask one question of every developer: what happens when the other system is down for two hours?

The answers vary enormously. "It retries with a delay and alerts us after the third failure, and nothing is lost" describes someone who has run integrations in production. "It'll pick up next time it runs" might be fine, or might mean four hours of orders vanish. "That shouldn't happen" means you should keep interviewing.

The silent failure is the expensive one. An integration that stops working loudly costs an afternoon; one that stops working quietly costs three weeks of reconciliation.

Sometimes the answer is a connector platform

Zapier, Make and similar tools genuinely solve a real slice of this work. For low volumes and simple flows, they cost a fraction of custom development and can be changed by someone who is not a developer.

They stop being the right answer when volume grows past their pricing tiers, when a silent failure is unacceptable, when the logic branches more than a few times, or when you need an audit trail per transaction. Ask each developer why they proposed custom over a connector — and treat "connectors are unreliable" as an incomplete answer.

The other end is not under your control

An integration depends on someone else's software, which changes on their schedule. Vendors deprecate API versions, tighten rate limits, and rotate authentication requirements. Credentials expire, often annually, often without warning anyone who would recognise the email.

So the maintenance question is not optional. Agree who watches for vendor change notices, who renews credentials, and what a fix costs when the other end moves. If the answer is your own team, make sure the documentation and access exist before the invoice is paid.

Xero, because this is New Zealand

Most integration briefs here include Xero somewhere, and it is worth knowing where the hours actually go. Not the connection — the mapping. Which account each kind of transaction lands in, how GST is handled, how customers are matched to existing contacts, what happens with credit notes and part payments, and how you avoid creating a duplicate every time something reruns.

A developer who has done this before will ask about your chart of accounts early. One who has not will discover it in week three.

What to compare across quotes

• Failure behaviour. Retries, alerts, and whether anything can be lost.
• Direction. One-way or two-way, and the conflict rules if two.
• Monitoring. Who is told, how, and how quickly.
• Vendor limits. Rate limits and API costs at your volume.
• Maintenance. Who handles the other end changing.
• Custom versus connector, with the reasoning.

Describe the data, not the pipe

Say which systems you run, what information should move, which direction, how often, and what goes wrong today when it does not. Developers who do this work weekly will tell you where the edge cases hide in your particular combination — and that, rather than the price, is what you are shopping for.