Custom Software Development in New Zealand

When custom is the right answer

Custom software is worth commissioning in a narrow set of situations. It helps to be honest about whether you are in one of them.

• The process is how you compete. If the way you quote, schedule or deliver is genuinely better than your competitors', software that encodes it protects the advantage. Software that forces you into a generic workflow destroys it.
• Nothing on the market fits. Industry quirks, regulatory requirements or a business model the products were not designed for. Real, but claimed far more often than it is true.
• The licence maths turned. Per-seat pricing across a large team, for years, can exceed a build. Do the three-year comparison rather than the monthly one.
• The spreadsheet became a risk. Several people editing, no history, no permissions, and a business that stops if the file is corrupted. This is the most common honest reason in New Zealand.

If none of those apply and a product does most of the job, buy the product. A developer who never suggests that is selling rather than advising.

Scope is what you are comparing, not rate

Hourly rates in New Zealand cluster between $120 and $250. That range explains a fraction of the difference between quotes. Scope explains the rest.

Give three developers the same three-paragraph brief and you will get a $40,000 proposal, a $95,000 proposal and a $180,000 proposal, all reasonable. The first built the core process and left everything else manual. The second added roles, notifications, an audit trail and an integration. The third included migrating fifteen years of history and running both systems in parallel.

Ask each of them what they left out. That conversation is worth more than the numbers.

Start with the smallest useful version

The most reliable way to waste money on custom software is to specify everything up front and build it in one pass. Requirements change while you build, some features turn out to be unnecessary, and nobody knows which until people use it.

Ask each developer what the smallest genuinely useful version looks like and what it costs. If the answer is "we have to build all of it before any of it works", ask why. Sometimes that is true — a system replacing a live process cannot go half-live. Often it is a way to avoid the harder question of what matters most.

The questions that decide the price

Four things drive cost more than anything else, and it is worth deciding your answers before the quotes arrive.

• How many kinds of user? One internal team is simple. Staff, managers, customers and suppliers with different permissions is four systems sharing a database.
• Does it integrate? Every system it talks to adds development, testing and a source of future breakage. Xero alone is straightforward; Xero, a CRM and a warehouse system is a project.
• Does old data come across? Migrating twelve years of inconsistent records is routinely a fifth of the budget and is where timelines slip.
• Who is it accountable to? Personal information, health data, payments or government contracts each bring obligations that change the build.

Ownership and the exit

Agree three things in writing before work starts: you own the code, you own the data, and you can take both elsewhere.

Ask what happens if you part ways in eighteen months. The good answer is a repository you already have access to, deployment documented, and an export of your data in a usable format. The bad answer is discovering that the code lives on the developer's laptop and the system runs on a server billed to their company.

This is not distrust. Businesses change, people move on, and a plan for that costs nothing to arrange at the start.

What it costs after it is built

Budget 15% to 20% of the build cost per year. Dependencies get security updates, platforms deprecate things, browsers change, and the business asks for adjustments. Software that receives no maintenance does not stay still — it degrades, quietly, until something fails at an inconvenient moment.

A quote with no ongoing figure is not cheaper. It is incomplete.

What to compare across quotes

• What each one excluded. The single most informative question you can ask.
• The smallest useful version, and its price.
• Annual running cost, including hosting and maintenance.
• Who does the work, and what happens if they leave.
• Ownership terms for code and data, in writing.
• A system still in use. Built two years ago, with a reference you can call.

Describe the problem, not the software

You do not need a specification or a technology preference. Describe the process as it runs today, who touches it, where it goes wrong, and what those failures cost. Developers who build these systems weekly will tell you whether you need custom software at all — and the ones who say you might not are worth listening to.