Scoping a complex B2B software project in NZ: what a discovery phase actually involves

Most custom software conversations start in the same place: a business knows it needs something built, has a rough idea of what it does, and wants to know how long it will take and what it will cost. Before either of those questions can be answered honestly, something else has to happen first. That something is called discovery — and in complex B2B projects, it is where the real work begins.

This guide is written for New Zealand businesses scoping a complex custom build: a trade portal, a custom ERP, a system that needs to integrate with several accounting or logistics platforms, or software that will run a core part of the operation. Not a brochure website or a simple internal tool. The kind of project where getting the scope wrong costs six figures and six months.

What "discovery" actually means

Discovery is a structured phase of work that happens before any code is written. Its purpose is to produce a clear, detailed picture of what the software needs to do — precise enough that the build team can estimate cost and timeline accurately, make informed architecture decisions, and avoid the class of problems that only appear when requirements are assumed rather than documented.

It is not a single kick-off meeting, and it is not a document that gets filed away. Done properly, discovery produces a set of outputs that govern the entire build. Done poorly — or skipped — those decisions get made during the build instead, under time pressure, with a partial picture of the requirements. That is how projects drift.

What a discovery phase produces

The outputs vary with project complexity, but for a serious B2B build the following should all exist by the time discovery closes.

Current-state process map

A documented picture of how things actually work today — not the idealised version, not the org chart version, but the real sequence of steps from trigger to outcome. For a food distributor, this might be: how a customer order arrives, how it moves through the warehouse, how it gets invoiced, and how payment is reconciled. Every deviation from the "official" process, every manual step that compensates for a gap in the current system, every place where two people do it differently — all of it surfaced and documented. Software built against the official process and not the actual one will be wrong from day one.

Systems inventory and integration map

For most complex B2B builds, the new software is not a replacement for everything — it needs to connect to systems that are staying. An accounting platform, a warehouse management system, a payroll tool, a customer database. Discovery maps every system in play: what data each one owns, what needs to flow between them, in what direction, at what frequency, and how errors should be handled when a sync fails. This is especially important for integrations with platforms like Accredo, Xero, MYOB, SAP, or NetSuite — each has its own data model and its own constraints, and discovering those constraints during build rather than during discovery creates expensive rework.

Functional requirements

User stories, use cases, or a feature list — the format matters less than the completeness. For each thing the software needs to do, a clear statement of who does it, under what conditions, what the outcome is, and what the edge cases are. For a B2B trade portal, this includes: how a customer places an order, how they see their contracted pricing, how credit hold is enforced, how a rep places an order on behalf of a customer, how back-orders are communicated. Every one of these is a design decision that can go multiple ways — getting it wrong means rebuild, not tweak.

Architecture decisions record

The core technology decisions that will shape the build: cloud provider and deployment model, database structure, API design, authentication approach, security model, data residency. For NZ businesses, this often includes a decision about whether data needs to be hosted in New Zealand — relevant for health, financial, and government-adjacent projects under the Privacy Act 2020. These decisions are significantly more expensive to change once build has started than they are to make correctly during discovery.

Scope boundary document

What is explicitly in scope, what is explicitly out of scope, and what is deferred to a later phase. The out-of-scope list matters as much as the in-scope list. In a complex project with many stakeholders, every person in the room has something they want the software to do. Discovery is where those requests are evaluated, prioritised, and assigned to phases — so the build team is not managing scope requests mid-sprint and the client is not surprised when something they assumed was included is not.

The workshops that produce these outputs

Discovery is not a solo research exercise by the build team. It is a collaborative process that requires time from your people. Typically across a serious discovery engagement:

• Stakeholder interviews. One-on-one conversations with the people whose work the software needs to support. Operations, finance, IT, and at least one front-line user. The questions are about current process, current friction, and current workarounds — not about features.
• Process mapping workshops. Group sessions that follow a transaction from start to finish — an order, an invoice, a stock movement — with the people who actually handle it. The goal is to surface every step, every decision point, and every exception. These sessions frequently reveal processes that nobody in leadership knew were happening.
• Integration scoping sessions. Technical sessions with your IT contact and the build team, working through each system that needs to connect. API access confirmed, data fields mapped, volume understood, constraints documented.
• Architecture review. A session with the technical lead and relevant stakeholders to walk through the proposed architecture, confirm the decisions are fit for purpose, and surface any constraints from your infrastructure or security policy.

NZ-specific considerations that affect discovery

Several factors are specific to New Zealand builds and should be addressed explicitly during discovery rather than assumed.

GST handling. New Zealand's GST model is relatively straightforward, but the implementation detail matters: whether prices in the system are stored inclusive or exclusive of GST, how rounding is applied across line items and order totals, and how the software generates GST-compliant tax invoices. For distributors running high invoice volumes, this is an audit and reconciliation consideration, not just a display question.

IRD record-keeping. Businesses are required to retain financial records for seven years. For a system that replaces or extends an accounting platform, discovery should address how historical data is preserved, how the cutover period is handled for GST period-end purposes, and what the data retention policy is for the new system.

Privacy Act 2020. Customer data — names, addresses, purchasing history, payment behaviour — is personal information under the Act. Discovery should establish how customer data is stored, who can access it, how long it is retained, and whether offshore hosting creates compliance obligations. If the system integrates with an offshore cloud accounting platform, those data flows need to be understood.

How to prepare as a client

The quality of discovery outputs depends on the quality of the input from your side. The things that make the most difference:

• Get your key operational people available for workshops — not just the project sponsor.
• Export data samples from your current systems so the build team can see real field names, formats, and volumes.
• Write down what your current system does badly — the workarounds, the manual steps, the things that break.
• Know which requirements are non-negotiable and which are preferences. The build team cannot make that distinction for you.
• Have IT credentials and API documentation for any system that needs to integrate — confirming access during discovery prevents delays at the start of build.

When discovery changes the brief

A well-run discovery phase often surfaces complexity that was not in the original brief. An accounting integration that is more involved than expected because of a non-standard pricing model. A workflow that turns out to work differently across two branches of the business. A compliance requirement that changes the data model. When this happens during discovery, it is a revision to the scope document — a low-cost, low-drama adjustment. When it surfaces during build, it is a change request, a timeline slip, and a budget conversation nobody wanted to have.

For a complex build decision, discovery is also where you confirm the build is the right call — or where an integration with existing systems turns out to be sufficient. See the replace vs integrate decision framework for a structured way to approach that question.

If you are scoping a complex custom build in New Zealand, talk to the Zeabyte team. We have run discovery for custom ERP builds, B2B trade portals, and deep multi-system integrations — and we will give you a straight read on what the discovery phase should cover, how long it will take, and what it will produce.