HighFlyer

Most business software says it works in New Zealand.

That is not the same as being ready for a New Zealand business.

A NZ-ready system does not need to replace everything you already use.

It should connect cleanly with your accounting software, whether that is Xero or another platform.

It should understand GST enough that finance does not export every month-end problem into spreadsheets.

It should support local payment flows, customer updates, approvals, reporting, permissions, and the little edge cases that show up after the demo.

That is the layer we like working in at HighFlyer.

Not forcing one system into every business, but making the tools you already trust work properly together, and building what is missing around them.

Sometimes that means a custom workflow. Sometimes it means an integration. Sometimes it means telling the customer not to build a new system at all.

The important question is not, "Can this software technically be used in New Zealand?"

It is, "Does it fit the way our business actually runs?"

If you are choosing or replacing software here, ask vendors what local workflows are supported by design, and what is expected to be handled by workaround.

What is one workflow your current software almost supports, but still leaves your team patching by hand?

Security is not a phase at the end of a software project.

It is the daily work.

When we build systems that handle customer data, payments, operations or financial workflows, the security decisions are not glamorous.

They look like permission boundaries tested before release.

They look like OAuth and API tokens stored as encrypted secrets, not copied into code.

They look like dependency scans, vulnerability scans and static analysis running before code reaches production.

They look like SSL, Cloudflare proxying and deployment checks treated as baseline, not extras.

They look like least-privilege roles for users, internal access and support workflows.

A good software partner should be able to explain how they prevent cross-tenant data access, how secrets are handled, who can deploy, and what runs before code reaches production.

This is not about pretending software can be made risk-free. It cannot.

It is about making security part of the engineering muscle memory, so the boring controls happen even when nobody asks for them.

If you are choosing a software partner, ask them what happens on an ordinary Tuesday before code ships.

Happy to compare notes. What is one security question you now ask vendors that you did not ask five years ago?

It's Friday afternoon. Your accountant sends you the monthly P&L. You scan it for two minutes, look for anything red, and put it away.

That's how most NZ business owners interact with their accounting data. Once a month. For two minutes. By the time anything looks wrong, you're three weeks behind reacting to it.

We built a small AI tool that reads your Xero P&L every night and writes a short note about what changed. Not the full report. Not numbers in a spreadsheet. A few sentences in plain English. "Sales are up 12% on last month, mostly from your Albany branch. Cost of Goods has crept up 4%, you may want to look at the dairy supplier line."

The hard part wasn't the AI. It was making it accurate enough that you'd trust it.

Our first attempt matched on section titles. "Sales" goes in the revenue bucket. "Expenses" goes in the expenses bucket. That worked for about a week, until we ran it against a Xero file that had been customised to suit a specific business. The AI started classifying revenue as expenses and panicking the dashboard.

The fix took some unpicking. We stopped reading the P&L like a human would and started pulling from Xero's underlying account classifications. Every account in Xero is tagged with what it actually is. The AI now reads those tags, not the section names. Accuracy went from "mostly right" to "right".

We also had to be thoughtful with running cost. AI isn't free. We cache what we can and only ask the model the questions a business owner would actually want answered.

We use it on our own books every week now. Two sentences a day beats two minutes a month.

If your P&L sits in Xero and you're only opening it monthly, you're flying blind for the other 29 days. Worth asking what you're missing.

When was the last time you looked at your numbers before someone else flagged a problem?

Every business owner we talk to has one. The thing they meant to fix in February. The spreadsheet that's still being updated by hand. The follow-up email someone still types out the same way every week.

We've heard ours a hundred times by now:

- Monthly stocktake reconciliation in Excel
- Pasting bank statements into MYOB line by line
- The "checking emails for new orders" Tuesday morning ritual
- Sending the same quote template every time, with five fields changed
- That one report the owner exports, manually reformats, and emails to the board on Friday

Most never get touched. Not because automation is hard. Because the manual version still works just well enough to keep happening.

So we're going to ask the obvious question, and we'd actually like to hear your answers:

What's the manual workflow you swore you'd automate this year, and still haven't?

Your analytics dashboard says you had 8,140 visitors last month. Your sales pipeline says nothing changed. One of them is lying to you.

We see this pattern on a lot of NZ business websites. The numbers go up and to the right. The actual conversations don't.

The usual culprit is bots. Search engines indexing your pages. Security scanners poking at your forms. SEO tools doing competitor research for someone else. They all show up in your dashboard as "visits".

Most analytics dashboards we audit are counting between 25% and 50% bot traffic. Sometimes worse. If your numbers feel disconnected from your actual sales pipeline, that's usually why.

The 8,140 visits above? After we filtered out the bots, the real number was 5,275. A third of what the dashboard reported was crawlers, scanners, and scrapers.

Filtering them out is harder than it sounds. The naive fix is to filter at the server, blocking known bot signatures before the page is served. That works for a while. Then it stops, because most modern websites are served from a fast cache layer that doesn't always ask your server who's visiting.

The fix we now bake into every SiteFlow site is to put the bot check inside the visitor's browser. Real people run the check just by loading the page. Most bots skip that step. Anything that doesn't complete the check gets tagged as "probably a bot" and stripped out of the numbers you act on.

Not great for the slide deck. Much better for the decisions you make with the data.

This is why our SiteFlow web service includes analytics and SEO setup, not just design and code. The dashboard you check every month should be telling you the truth.

When was the last time you cross-referenced your website analytics with your actual sales pipeline?

You're about to hire someone to build software for your business. They're going to disappear into their laptops for three months and come back with something you'll live with for the next five years. Here are five things worth asking them on the first call.

1. Have you ever told a client not to build something?

If the answer is no, every project they take is one they can sell. Not one that should exist. The right answer comes with a story.

2. Who actually writes the code, and where do they live?

Many shops sell the senior consultant and deliver with juniors you'll never meet. Not always bad. But you need to know who's behind the keyboard.

3. If you're hit by a bus next year, what happens to my business?

Tests for documentation, code ownership, account access. The boring stuff that quietly decides what year two looks like.

4. Can I see something you built two years ago that's still in use?

A working demo from last week is easy. A system that's been running for years means it didn't quietly collapse the moment your invoice cleared.

5. What does this look like if we never call you again?

If the answer is "nothing works", you're not buying software. You're buying a leash.

We've answered all five of these for clients on first calls. Sometimes it loses us the work. We're OK with that.

What's the question you wish you'd asked the last team you worked with?

Imagine waking up on a weekday and finding an email already in your inbox.

It tells you which orders are still waiting to ship, which quotes have gone silent, which invoices are overdue, which bills are due this week, and the three highest-leverage things to do today.

You read it over your first coffee. You finish your coffee already knowing what to do.

That used to be a chief-of-staff function. For a small business it's now an engineering problem with a known solution.

We build these for NZ SMEs whose data is good enough to power a chief-of-staff function but whose headcount isn't: automated morning briefings, weekly cash and order summaries, scheduled board reviews. Three things we've learned:

1. The most useful agents are scheduled, not interactive. The owner doesn't ask the system questions, the system tells the owner things on a schedule. This is the opposite of how most people use ChatGPT, and it's part of why most ChatGPT-style tools haven't changed how SMEs actually run.

2. Defaults beat dashboards. Nobody logs into four systems every morning before deciding what's important. The briefing has to come to the inbox, already filtered to "what changed since yesterday".

3. Hallucinations matter less when every claim links to its source. Each line in a useful briefing is a clickable link to the underlying record. Trust comes from "I can verify this in one click", not from the model sounding clever.

A build for an SME of under 10 people typically takes a few weeks. Maintenance is close to zero. Running cost is closer to a Mac mini and an API subscription than a salaried analyst.

We built the first one of these for our own business and have been running it for the last two months. We're now building them for clients.

If you're spending 30+ minutes every morning checking four or five systems before you can decide what to do, you're a candidate for one of these.

What's the morning information ritual eating 30+ minutes of your day?

When an NZ SaaS hires us to build their billing engine, the Stripe integration takes a day. The NZ-specific tax logic on top takes a week.

That ratio surprises every new client. The off-the-shelf integration is the easy part. The layer on top that tells the off-the-shelf system how NZ businesses actually operate is the hard part.

Three NZ-specific rules show up in almost every project we take on, and almost every off-the-shelf API, library, or third-party integration gets them wrong by default:

1. Tax across borders. A NZ SaaS billing customers in Tokyo, Berlin, and Austin doesn't just charge "15% GST". It needs Japan Consumption Tax thresholds, EU VAT, US state-by-state sales tax, and NZ's own zero-rating rules for exported services. Each one has different rules for B2B vs B2C. Off-the-shelf billing libraries default to one tax line. We end up writing a tax engine on top.

2. GST mechanics. When we build invoicing or accounting integrations for NZ SMEs, we can't assume "invoice basis, monthly". NZ has three filing methods (invoice, payment, hybrid), three filing frequencies, and a $60k registration threshold. Most off-the-shelf invoicing libraries model only invoice basis. For payment-basis NZ businesses, we have to build a parallel ledger that recognises revenue on payment receipt.

3. Bank reconciliation. When we build payment systems or sync layers for NZ businesses, there's no open-banking standard to pull from. The five major NZ banks each export differently. A naive Stripe → Xero integration creates payout entries that don't reconcile to NZ bank lines. We end up writing matching layers between Stripe's payout descriptors and ANZ / BNZ / ASB transaction formats.

The pattern: software written somewhere else assumes everywhere is somewhere else. Building software for an NZ business means building the layer that makes off-the-shelf behave like it's in NZ.

If you're scoping a build with a vendor and they haven't asked about your GST filing basis, your bank, or your customers' geography, they're probably going to discover those things in production.

What's the NZ-specific gap in off-the-shelf software that you've had to work around in your business?