How to evaluate and choose a custom software development partner in NZ

Selecting a custom software development partner is genuinely different from selecting a SaaS product. With SaaS, you can trial the software before committing. With a custom build, you are committing before the software exists — which means you are selecting on evidence of capability, not on the thing itself.

Most NZ businesses treat this process informally: a few conversations, a comparison of quotes, a gut-feel decision. For a small internal tool, that is fine. For a custom ERP, a B2B ordering platform, or a system that will run core operations, the selection decision shapes the next three to five years of the business. It deserves a structured approach.

This guide covers how to run that process — from the first longlist to the moment you sign — with the NZ-specific considerations that generic vendor evaluation frameworks omit.

Start with what you actually need to evaluate

Before you contact any vendor, get clear on what you are actually trying to learn. The useful question is not "who can build this?" — most vendors will say yes to anything at the proposal stage. The useful question is: "which vendor has done something close enough to this that their estimate and their delivery will reflect reality?"

For a complex B2B software project, the relevant track record includes:

• Systems similar in complexity — not just "custom software" but custom software at the integration depth your project requires. A vendor who has built consumer apps is not the same as one who has built systems that integrate bidirectionally with Accredo, MYOB Acumatica, or SAP in production.
• Clients in a similar operating context — NZ mid-market businesses, with similar process complexity, not a portfolio of offshore enterprise logos that tell you nothing about local operating experience.
• Delivered projects, not ongoing engagements — a vendor who has completed and handed over complex builds has demonstrated they can get something to production. A vendor with a client list of systems "in build" has not.

Build a longlist, then shrink it fast

Start with six to eight candidates from referrals, directory listings, and your own research. The NZ market for complex B2B software is small enough that word of mouth from other mid-market businesses in your sector is often more reliable than directory rankings.

Shrink the longlist to three or four within the first week using a single structured conversation with each vendor — not a demo, just a conversation. The goal is to eliminate obvious mismatches before you invest time in a detailed evaluation. Three disqualifying signals that show up in the first call:

• They do not ask about your current systems. Any vendor experienced in NZ B2B software will ask early what ERP or accounting platform you run. The integration question is not an afterthought — it shapes the complexity of the project. A vendor who does not ask is either inexperienced or planning to discover the constraints later, when it is expensive.
• They offer a fixed price before understanding the scope. A fixed price quoted before any structured discovery work means one of two things: they have padded it to cover uncertainty, or they have not thought through what the project actually involves. Neither is reassuring.
• You cannot talk to the engineers during the sales process. Strong vendors involve technical people in the sales conversation because they want you to understand who will actually build your system. If every conversation is with a business development person and the engineers only appear after signing, you are evaluating the sales team, not the build team.

Structured assessment of the shortlist

With two or three vendors, move to a structured assessment. This is not a traditional RFP — asking vendors to price a solution before the problem is understood produces bad quotes, not good information. It is a working session: bring your current process, your existing systems, and your constraints, and ask the vendor to demonstrate how they think about the problem.

Evaluate on five dimensions. Score each vendor against each before you compare across vendors — cross-vendor comparison too early anchors on the vendor you evaluated first.

• Problem understanding. Can they describe your problem back to you more accurately after the session than before? Do they identify constraints you had not raised? Do they ask about the edge cases in your process, not just the main workflow?
• Relevant experience. Not portfolio slides — ask for a specific walkthrough of a similar project: what the integration looked like, what went wrong, how they handled it. Generalities are a signal. Specifics are evidence.
• Delivery approach. How do they manage scope during a build? What does their change control process look like? How do they structure UAT? What support arrangements exist post-go-live? If these are not defined processes, they will be improvised during your project.
• NZ-specific knowledge. For software that touches financial data, ask how they handle IRD seven-year record-keeping in the data design. For systems handling customer data, ask how they approach NZ Privacy Act 2020 obligations — particularly IPP 3A indirect collection if you are syncing contacts from an ERP integration. Vendors without practical answers to these have not built production systems at this level in NZ before.
• Commercial fit. Not just rate — the structure of the engagement. Do they work on fixed scope, time and materials, or a hybrid? How is the discovery phase priced? What triggers a change request? How is IP ownership structured? These questions surface problems before they become disputes.

Reference checks: ask about what went wrong

References offered by a vendor will be satisfied clients. That is useful baseline information — a vendor with no referenceable clients is a red flag — but it is not sufficient. Push to speak to a client whose project encountered a significant problem.

The most informative reference check questions focus on adversity: what was the most difficult point in the project, and how did the vendor respond? Was the final cost within the original estimate, and what drove any difference? What would they do differently? How was post-go-live support? A vendor who has navigated a difficult situation well — and whose client will say so — is more reassuring than a vendor with a clean record you cannot interrogate.

For NZ-specific assurance, ask references about the vendor's understanding of local requirements: did they raise NZ compliance considerations during the project, or did the client have to? Were integration partners (Accredo consultants, IT providers, ERP vendors) coordinated effectively?

The paid discovery sprint: test before you commit

Before signing a full build contract, the most reliable way to verify that the vendor can do what they say is to pay them to do a small piece of it. A paid discovery sprint — typically two to four weeks — produces a documented scope, an architecture decision record, and a realistic estimate for the full build. It also produces direct experience of the working relationship: communication style, responsiveness, quality of documentation, how they handle uncertainty.

A vendor who resists a scoped discovery phase and pushes straight to a full contract is worth questioning. Good vendors encourage it — they know that a properly scoped project delivers better outcomes for both parties, and that discovery work they have done is far more defensible than a price quoted from a one-hour conversation.

The discovery phase guide covers what a structured discovery engagement produces and how to prepare for one as a client.

What a completed evaluation should tell you

By the end of a structured evaluation you should be able to answer: does this vendor understand my environment specifically — my ERP, my processes, my NZ compliance obligations — or are they describing a generic build approach? Do their references confirm they deliver at the complexity level my project requires? Do I understand what happens when something goes wrong during the build, not just what happens when it goes right?

If you cannot answer these questions confidently, the evaluation has not produced enough information. The temptation is to proceed anyway and trust that it will work out. For a system that will run core operations — an ERP, a trade platform, a multi-system integration — that trust is expensive when it is misplaced.

If you are at the evaluation stage — or questioning whether a current vendor relationship is heading in the right direction — talk to the Zeabyte team. We build custom ERP and operational software and B2B ordering platforms for established NZ businesses, with deep integrations into Accredo, MYOB, SAP, NetSuite and more. We are also happy to explain how we approach the questions above in our own work. The custom software development guide covers what to expect once you have selected a partner, and the project governance guide covers how to structure the build once it starts.