Skip to content
← Back to articles
Custom Software
Pricing

Custom Software Cost NZ: Scope, Rates and Budget Examples

Compare scoped software budgets using NZD rates, clear assumptions, ownership costs and a downloadable quote worksheet.

By Rupert GoughPublished Updated
Custom Software Cost NZ: Scope, Rates and Budget Examples

The practical answer

A useful budget combines an assessed scope with development, migration, testing and ongoing costs. The examples show arithmetic at Lightning’s NZ$200/hour ad hoc rate plus GST; their hypothetical hours are not project quotes.

Discuss your business technology requirements, users and existing tools so we can define a useful website or web app scope. Discuss your website or app.

On this page 5 sections

A useful software budget starts with one outcome: who needs to do what, with which information, and how you will know it works. A quote for a form is different from a quote for the complete approval, migration and support process around it.

Lightning’s published ad hoc development rate is NZ$200 per hour plus GST. A project total needs an assessed scope; a rate alone is not a quote. See current pricing and engagement options.

Three examples of how a budget is assembled #

The following hours are invented planning inputs to demonstrate the arithmetic, not typical project estimates or offers. All amounts are NZD excluding GST. A real proposal could require substantially different work.

Illustrative build budgets at NZ$200/hour + GST
Scope exampleAssumed hoursBuild subtotalImportant boundaries
An enquiry form and staff review queue4 discovery + 10 build + 6 test/handover = 20$4,000 + GSTOne form and staff role. No historic migration or external integration assumed.
One department approval workflow10 discovery + 34 build + 16 test/migration/training = 60$12,000 + GSTOne agreed process and defined roles. External API work must be assessed separately.
A client document-request portal20 discovery + 68 build + 32 security tests/migration/handover = 120$24,000 + GSTIllustrates multiple roles and client separation. File volumes, identity checks and integrations can change effort.

The smaller number is only useful if the scope still solves the problem. Compare deliverables and acceptance checks before comparing totals. These examples exclude ongoing hosting, third-party subscriptions, internal staff effort and future changes.

Build a complete ownership budget #

Costs to collect before comparing options
CostAsk forAvoid this mistake
Discovery and designOutputs, assumptions, decision owners and what happens if the build does not proceedAssuming an exploratory conversation includes a buildable specification
ImplementationFeatures, roles, integrations, migration and exclusionsComparing a demo with a production-ready system
Testing and launchPermission tests, data checks, training, fallback and acceptanceLeaving these outside the budget
Ongoing operationHosting, backups, monitoring, updates, licences and response arrangementsTreating a hosting charge as an all-inclusive care service
Change and exitChange rates, account/code ownership, exports and handoverAssuming custom software has no dependencies

A three-year comparison can use: one-off implementation + 36 × monthly running costs + planned upgrades + internal transition effort. Keep GST treatment consistent. Do not add time saved as a reduction in cash cost unless it will actually avoid spending or produce measurable financial benefit.

Why apparently similar quotes differ #

A portal can mean a shared folder behind a login, or separate client accounts with upload checks, delegated access, audit history and support. An integration can mean a manual export or a monitored connection that handles duplicates, revoked access and failed requests. Ask each supplier to price the same journey, including exceptions.

For personal information, include access, retention and data-handling requirements at the beginning. The Privacy Commissioner’s principles are a starting point for agreeing responsibilities; buying software does not establish compliance.

Compare a smaller first version #

For a quoting problem, a useful first release might accept an enquiry, let a person approve the quote and record the customer’s decision. A full CRM, staff intranet and executive dashboard can wait unless they are necessary to that outcome. Also test whether configuring software you already own would solve it.

A quote comparison you can actually use #

Give both suppliers the same sample inputs and ask them to describe a successful result, one rejected request and one integration failure. Record what each price includes, what it assumes and what remains your responsibility.

Download the quote comparison worksheet (CSV). Open in a spreadsheet or text editor; the example rows are illustrative.

Before agreeing to a build, you should be able to name the first useful outcome, its acceptance checks, the total initial budget, ongoing obligations, and the process for approving changes. The brief-to-launch guide explains how those decisions fit into delivery.

A useful companion: Automation ROI Calculator.