HighFlyer

HighFlyer Web design. Custom software. AI automation. From New Zealand, for businesses worldwide. Strategic insight meets engineering excellence.

HighFlyer was founded with a vision to bridge the gap between strategic business consulting and technical implementation. We recognised that many organisations struggle to translate strategic initiatives into practical software solutions. Our journey began with a small team of consultants and engineers who shared a passion for solving complex business challenges through innovative technology. Toda

y, we specialise in custom software development, AI automation, and system integrations—building everything from SaaS platforms to intelligent chatbots and API-driven solutions. Headquartered in Auckland, HighFlyer now serves clients globally as a trusted partner for digital transformation. We combine deep technical expertise in areas like payment integrations and enterprise systems with strategic insight to help organisations leverage technology for competitive advantage.

Your analytics dashboard says you had 8,140 visitors last month. Your sales pipeline says nothing changed. One of them i...
28/05/2026

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 thre...
26/05/2026

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...
21/05/2026

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...
19/05/2026

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?

Every morning the inventory job died. Someone restarted it. Same story the next morning. Eventually it stopped restartin...
14/05/2026

Every morning the inventory job died. Someone restarted it. Same story the next morning. Eventually it stopped restarting at all.

This is the third time we've watched the same pattern in the last six months. An automated job, pushing stock to Shopify, syncing orders from WooCommerce, dispatching scheduled customer deliveries, runs for hours and times out. Someone bumps the time limit. It works for a week. Then it breaks again. Bumped again. Works. Breaks.

The instinct is to keep raising the timeout. The instinct is wrong.

In the Shopify case, an inventory sync was meant to run every hour. The store had about 7,300 items. The old approach was making roughly 14,600 individual requests with a one-second pause between each. The arithmetic alone put it over two hours. No timeout was ever going to fit.

We rebuilt it to send updates in batches of 250 instead of one-by-one. Same store, same data:
- Before: 14,600 calls, 3+ hours, timed out
- After: ~30 calls, 11 seconds, done

The same shape of problem hit a WooCommerce sync earlier this year and an auto-delivery automation for an NZ food manufacturer more recently. Different code, same root cause: a job designed for ten orders running against ten thousand. The fix is never "make the timeout bigger." It's "stop doing ten thousand things one at a time."

If you have a scheduled job that needs babying, restarted, retried, given more time every few months, the timeout isn't the problem. The shape of the work is.

Full write-up of the Shopify rebuild including the retry logic: https://highflyerglobal.com/blog/2026/04/29/erpnext-shopify-inventory-sync-graphql-rewrite/

What's a job in your business that someone has to "go and kick" once a week?

A customer running a brand selling into Europe and Asia asked us to add language support to their site. They thought it ...
12/05/2026

A customer running a brand selling into Europe and Asia asked us to add language support to their site. They thought it was a translation job. It wasn't.

If your site reads in Korean but the date format is American, the address line says "State" when nobody in that country uses one, and the price is listed in NZD because you forgot the converter, the language doesn't save you. A reader in Seoul is still going to bounce.

What the customer actually needed was English, Dutch, and Korean, with each market seeing the things that signal "this site was built for me." Local date format. Local currency. Address fields that match how people actually live. A language switcher that doesn't reload the whole page and lose the visitor's place.

We built the site so the language switches inline, instantly, with the visitor staying exactly where they were. The translations were the easy part. Getting every other detail right. That was where the work lived.

If your business sells outside New Zealand and your site is "translated", you're probably losing visitors who think it isn't really for them. They won't tell you. They'll just leave.

What's the smallest signal a website gives you that it wasn't built with your country in mind?

Most NZ beauty and wellness clinics pay $20 to $25 per staff member per month for booking widgets like Calendly or Acuit...
07/05/2026

Most NZ beauty and wellness clinics pay $20 to $25 per staff member per month for booking widgets like Calendly or Acuity. Five practitioners is over $1,000 a year just to let customers pick a time.

Every one of those clinics already pays for Google Workspace. And Google Calendar has an API.

We built TrueGlow's booking system directly against Google Calendar. Customers see real-time availability. When they confirm, the booking lands as a calendar event the practitioner sees instantly in their normal Google Calendar app. The customer gets an email with an iCal attachment so it goes into their calendar too. In English and Mandarin, because the Auckland clientele needs both.

Adding staff doesn't add cost. Google Calendar's API exposes per-staff availability natively, so the same setup handles one practitioner or fifteen. Microsoft 365 with Outlook works the same way.

Beyond cost, the win is ownership. The practitioner's calendar is the source of truth. Block out a holiday in your normal calendar app and the booking page reflects it instantly.

If you're paying per-seat for a booking platform, ask your dev team: what would it take to do this against the calendar tool we already pay for?

What's a SaaS you're paying for that's quietly replacing something you could already do yourself?

The naive Xero integration is five lines of code. Submit a sales invoice locally. Map it. Call xero.invoices.create. Don...
05/05/2026

The naive Xero integration is five lines of code. Submit a sales invoice locally. Map it. Call xero.invoices.create. Done. It works on a sunny afternoon with one worker and no traffic.

Then you put it in production.

The worker dies halfway through pushing an invoice. The local doc is submitted, Xero never received it. The worker restarts, retries, and now there are two invoices in Xero. Someone cancels the doc in your system while it's being pushed. Xero has it, your system says it doesn't. A line item has no tax code resolved and the user sees "something went wrong."

Each of these is an engineering decision, not a tutorial line.

We built the connector that pushes invoices from NexWave to Xero. The five things it does that most tutorials skip:

1. Background queue with enqueue_after_commit, so the user doesn't wait for Xero. The push is queued only if the local transaction commits.
2. Idempotent by remote lookup, not by local flag. We ask Xero "do you already have this invoice number?" before creating. Source of truth lives at Xero, not our state.
3. Re-check docstatus after the API call. If the doc was cancelled mid-push, void the Xero invoice automatically.
4. Tax resolution with a fallback chain (line template, doc template, item default, company default). If all four miss, fail with a specific actionable error.
5. A recovery path for documents stuck in queued state, with manual retry and orphan detection.

Underlying pattern: every decision assumes something will go wrong. Idempotency means duplicates can't happen. Re-checking means silent desync can't persist. Queued sync means a slow Xero never slows the user.

Reliability isn't defensive code. It's choosing data structures that make the wrong outcomes impossible.

Full breakdown: https://highflyerglobal.com/blog/2026/04/08/xero-integration-that-survives-crashes/

What's the most expensive assumption your last integration made about happy paths?

New Zealand's banking system has a quirk that makes automatic bank feeds harder than it should be.Unlike markets with es...
30/04/2026

New Zealand's banking system has a quirk that makes automatic bank feeds harder than it should be.

Unlike markets with established open banking APIs, NZ banks didn't offer direct data feeds to third-party software until recently. Businesses downloaded CSV files, reformatted them, and imported them manually. Every bank had a different format. Every accountant had a different workflow for dealing with it.

We integrated our ERP platform with Akahu, New Zealand's open banking platform. Bank transactions from ANZ, ASB, BNZ, Westpac, and Kiwibank now sync automatically.

The OAuth connection was the easy part. The engineering challenges were in the details.

Duplicate detection: if a sync job runs, partially completes, and retries, you can't import the same transaction twice. A duplicated bank transaction throws off your reconciliation and takes longer to find than it does to prevent. We built idempotent import logic that checks transaction references, dates, and amounts before creating anything.

Bank-specific metadata: each bank returns different fields. Some include merchant names, others don't. Reference fields, particulars, and transaction codes vary in format and reliability. The sync layer normalises all of this into a consistent format before it hits the reconciliation tool.

Background reliability: the sync runs on a schedule without manual intervention. When it fails (network timeout, API rate limit, expired token), it needs to fail visibly, retry intelligently, and never silently skip transactions. After the silent failure investigation we shared recently, we take this very seriously.

The result: open the reconciliation tool, match transactions to invoices, done. No downloads. No format conversion. No "which bank was that CSV from?"

What's the most tedious financial workflow you've managed to automate away?

$1,150 on the swing tag. $1,000 in the ERP. Every line, every transaction. Forever.This is why NZ businesses keep bounci...
28/04/2026

$1,150 on the swing tag. $1,000 in the ERP. Every line, every transaction. Forever.

This is why NZ businesses keep bouncing off cloud ERP platforms after expensive implementations.

We've spent a lot of this year migrating businesses off platforms that were technically capable but quietly making their finance teams miserable. The pattern is always the same. Six weeks in, the accounts team asks "why do we have to enter prices exclusive of tax? We've always worked inclusive."

The implementation partner shrugs. "That's how the system works."

Here's what's actually happening. NZ retailers, trades, hospitality, and most professional services quote and sell in GST-inclusive terms. The shelf price is gross. The bookkeeper looking at a bank statement sees gross. Xero supports this natively (Tax Inclusive toggle, per-organisation default, the inclusive price as the natural input). Most cloud ERPs designed for other markets do not. They force tax-exclusive entry and compute GST on top.

Multiplied across 200 invoices a month, your sales staff stop doing the mental arithmetic and just enter the gross. Your accountant finds out at month-end when GST returns won't reconcile. Manual fixes pile up. Spreadsheet workarounds appear. The ERP starts feeling like a bad fit, and a year later you're back on Xero.

This isn't an exotic feature request. It's matching how the country actually does accounting.

If you're evaluating an ERP, the test isn't "does it compute GST." Every system does. The test is whether your sales staff can enter the swing-tag price without a mental conversion, and whether your bookkeeper can record a gross JE and have the system split it correctly.

We rebuilt this end-to-end for NexWave (the ERP we maintain for NZ/AU). Wrote up the why and the how here: https://highflyerglobal.com/blog/2026/04/12/why-imported-erps-fail-nz-businesses/

What's the smallest piece of friction in your finance workflow that you've stopped noticing?

We had a client whose stock GL accounts and stock ledger hadn't agreed since go-live. Eight months of manual workarounds...
23/04/2026

We had a client whose stock GL accounts and stock ledger hadn't agreed since go-live. Eight months of manual workarounds had compounded the problem into a tangled web of journal entries, temporary accounts, and phantom balances.

The investigation required tracing 3,600+ historical transactions, cross-referencing GL entries against the stock ledger warehouse by warehouse, simulating the impact of each proposed correction before applying it, and discovering a hidden double-counting error in the opening balance import that nobody knew existed.

Here's the thing: we did the entire analysis, simulation, and fix plan in a single working session. Not because we're that fast. Because we used AI as a genuine engineering partner throughout.

Not AI generating boilerplate code. AI working against an up-to-date backup we restored locally (taken the day before, so every transaction we needed was in it). Building running balance simulations. Tracing money flows across dozens of journal entries. Spotting patterns in thousands of GL records. Dry-running every change to predict the exact final state before anything touched production.

The kind of forensic accounting analysis that would normally mean days of exporting to spreadsheets, building pivot tables, and manually cross-checking was done interactively. Ask a question, get the data, follow the thread, ask the next question.

By the end of the session: every stock GL account matched the stock ledger to the cent. A $295k phantom AR credit was identified and resolved. A failed item valuation repost (stuck for months) was diagnosed and fixed. And we had a complete documented plan for the remaining cleanup.

This is what AI actually looks like in practice for a small engineering team. Not replacing the engineer. Making a single engineer effective at work that would normally need a team and a week.

We're a small company in Auckland. AI doesn't make us bigger. It makes us faster at the hard stuff.

How are you actually using AI in your day-to-day work? Not the pitch deck version, the real version.

Address

Suite 15703 Unit A/26 Hobson Street
Colombo 03
1010

Opening Hours

Monday 08:00 - 17:00
Tuesday 08:00 - 17:00
Wednesday 08:00 - 17:00
Thursday 08:00 - 17:00
Friday 08:00 - 17:00

Telephone

+442032394486

Website

Alerts

Be the first to know and let us send you an email when HighFlyer posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to HighFlyer:

Shortcuts

Share