A Wellington founder stands at a whiteboard with two columns. On the left: monthly subscriptions, product work, overseas sales. On the right: consulting fees, customer projects, cash this month. The team is small, runway is tight, and every arrow seems to lead to a different risk.
That's the SaaS vs non-SaaS decision that matters for Kiwi and Australian founders. Investors may favour product revenue, but a small home market, limited engineering talent, and demanding customers can make services the sensible first move. The question isn't which label sounds better. It's which model gives your team enough cash, learning, and market access to survive long enough to build something repeatable.
New Zealand's broader software and IT services economy shows why the choice matters. Stats NZ estimated $14.5 billion in total sales of published software and IT services in 2023, made up of $4.9 billion in published software and $9.6 billion in IT services, according to the Stats NZ ICT supply services and software survey. Software products represented about 34% of that combined total, while services represented about 66%.
So, yes, SaaS is growing quickly. But non-SaaS is still the bigger local revenue pool. That's why the messy middle deserves more attention than it usually gets.
A subscription alone does not make a business SaaS. Start with how customers receive value, because founders often compare unlike models and then struggle to explain the economics.
In the New Zealand policy view, software as a service is centrally hosted software that customers access over a network and pay for through an ongoing subscription. The vendor runs the core application, maintains the platform, and provides access without requiring each customer to install and manage the main software locally. The SaaS business model guide from NZ Apps gives a practical explanation of this structure.
That definition separates SaaS from several neighbouring models:
The boundaries get fuzzy fast. A construction platform might charge a subscription, then bill separately for implementation and workflow design. A geoscience product might combine software, specialist data, training, and technical support. Xero shows how a local company can turn professional expertise into a repeatable product stack, while Seequent illustrates how specialist software can still require domain knowledge and customer support.
That middle ground is not a failure to become SaaS. For New Zealand founders facing a small domestic market and tight technical talent supply, it can be the right operating model and an export path.
Practical rule: If your customer still needs your people to make the software useful, price and staff that service explicitly. Don't hide a consultancy inside a subscription and then wonder why margins disappoint.
Label the business by how value is delivered, not by the pitch deck. If most revenue comes from repeat access to the same product, you have a SaaS core. If revenue depends on projects and billable expertise, you have a services core. If both reinforce each other, call it hybrid and model it that way.
The cleanest comparison is financial, not fashionable. A five-person team needs to know how the next customer changes cash flow, delivery load, and hiring pressure.
| Dimension | SaaS model | Non-SaaS model |
|---|---|---|
| Revenue shape | Recurring subscription revenue from an existing product | Project fees, retainers, licences, support, or managed delivery |
| Pricing mechanics | Per seat, tier, usage, or account | Fixed fee, time and materials, milestone billing, or daily rates |
| Gross margin profile | Often higher because one product serves many customers | Often lower because delivery depends on people and project effort |
| Customer acquisition | Longer payback can be acceptable if retention is strong | Revenue may arrive sooner after a signed project |
| Support burden | Product support, uptime, training, and account management | Delivery teams, implementation, troubleshooting, and ongoing service |
| Revenue concentration | Many smaller accounts can reduce dependence on one client | A few large projects can dominate the month or year |
| Cash conversion | Subscription billing can smooth receipts, but product work comes first | Deposits and milestone invoices can fund delivery earlier |
| Capital needs | More product, engineering, security, and infrastructure investment before repeatability | More people, sales capacity, project management, and working capital |
| Growth constraint | Churn, product adoption, support capacity, and distribution | Utilisation, hiring, delivery quality, and founder involvement |
| Tax and accounting | Deferred subscription revenue may be recognised over the service period | Services income is generally recognised as work is delivered under the agreed arrangement |
The common shorthand says SaaS carries 70% to 80% gross margins, while services sit around 30% to 50%. Treat those as planning ranges, not promises. A support-heavy SaaS business can perform worse than a tightly run specialist consultancy, while a mature product with clean onboarding can leave services behind.
New Zealand's cost data makes the infrastructure question more concrete. A public-sector productivity analysis estimated NZD 18,815 per user for on-premises platforms and software, compared with NZD 1,300 ongoing per user for public-cloud platforms and software, plus about NZD 5,500 migration cost per user. It also estimated a basic on-premises workload server at NZD 257K, compared with NZD 27K for an equivalent public-cloud configuration, as shown in the New Zealand digital government productivity analysis.
For a small team, the interpretation is simple. SaaS usually places more cost before the sale, then gives each successful product improvement a chance to serve many customers. Services can invoice earlier, but each new project often brings more coordination, delivery, and people cost. Founders comparing these paths should model retention, delivery hours, implementation time, and payment timing together. A useful customer lifetime value guide can help, but the spreadsheet still needs your actual support and sales assumptions.
Founders often overestimate feature breadth and underestimate local friction. Buyers in New Zealand and Australia usually care about whether the system fits their existing work, whether someone can help during implementation, and whether the vendor understands their operating environment.
A small manufacturer may want a clean connection with Xero or MYOB, not a grand Salesforce-native architecture. A regional council may ask where data is hosted and who can access it. An Australian retailer may care less about a clever roadmap than a credible local reference and a support contact who understands its reporting cycle.
| Buyer priority | Pure SaaS fit | Non-SaaS or hybrid fit |
|---|---|---|
| Data sovereignty and onshore hosting | Possible, if the vendor offers suitable hosting and controls | Often easier to explain through local delivery and contractual support |
| Xero or MYOB integration | Strong when connectors are mature | Strong when implementation staff can adapt workflows |
| Thin internal IT teams | Good for managed product operations | Good when the vendor supplies hands-on support |
| Local currency and contracts | Straightforward when billing supports NZD or AUD | Natural through local invoicing and account management |
| Implementation guidance | Limited in a self-serve motion | Usually a core part of the engagement |
| Local references | Harder for an early product | Easier to build through direct projects and partnerships |
| Regulated procurement | Requires clear security evidence | Can benefit from a service layer around the product |
The commercial lesson is awkward but useful. A pure self-serve product may be elegant, yet a buyer with a thin IT team may still want someone beside them during migration. That doesn't mean the product has failed. It means implementation is part of the product experience in this region.
Security evidence also changes the sales conversation. A founder selling into larger organisations may need a clear view of controls, access, incident handling, and vendor responsibility. A practical SOC 2 compliance guide for NZ and AU SaaS can help frame that work without pretending compliance is a box you tick once.
Sales motion matters too. Some teams need a founder-led process, partner referrals, or targeted outbound before product-led acquisition has enough momentum. If you're building that motion, specialist support such as hire cold callers may help create conversations, but it won't replace a sharp offer or credible proof.
The buyer's country matters. A Kiwi manufacturer may reward local implementation. An Aus-listed retailer may expect stronger procurement and security evidence. A council may value accountability and continuity over a flashy feature set. Same product category, different buying risk.
The theory becomes clearer when you follow the next dollar through three plausible businesses.
A Wellington founder has built scheduling software for construction firms. The product solves a real problem, but the local market is tight and each builder wants a slightly different workflow. The founder faces a choice: keep funding product improvements, or hire offshore developers and push harder on sales.
The SaaS route gives the company a repeatable product and a cleaner export story. It also carries churn risk, onboarding work, integration demands, and a long period where engineering bills arrive before subscription revenue feels meaningful. The sensible move may be a narrow product with paid implementation, not a broad platform built for every contractor.
The next dollar should answer one question: does this customer create reusable product value, or only more custom work?
An Auckland digital agency has grown through design, development, and consulting projects. Its cash flow is real, and clients value the team's judgement. But utilisation has become the ceiling. When the pipeline slows, revenue falls. When the pipeline improves, the founders struggle to hire quickly enough.
Productising an internal tool could help, but only if customers share the same pain and accept a repeatable workflow. The agency shouldn't rush to turn every internal spreadsheet into software. It should first identify the work that repeats, the decisions that don't need bespoke treatment, and the support customers will still pay for.
Services can fund discovery. Product should earn the right to exist.
A Christchurch founder sells a specialist platform to councils across New Zealand and Australia. Customers pay a base subscription, then separate site implementation and training fees. The product creates repeatable value, while local delivery handles procurement, data setup, and operational change.
This model won't look as pure in an investor spreadsheet as self-serve SaaS. It may produce a steadier runway, though, because the founder can charge for the work that would otherwise consume the team for free. Over time, implementation should become more organised, more documented, and less dependent on the founder.
| Scenario | Main strength | Main risk | Sensible direction |
|---|---|---|---|
| Wellington vertical SaaS | Repeatable product and export potential | Churn, custom requests, slow early payback | SaaS core with paid onboarding |
| Auckland agency | Early cash and strong customer learning | Utilisation ceiling and hiring pressure | Services core with selective productisation |
| Christchurch hybrid | Product revenue plus paid delivery | Operational complexity | Subscription plus implementation model |
The same revenue question appears in all three cases: what happens after the sale? If each new customer adds similar product revenue with little extra labour, SaaS has the edge. If each customer needs judgement, configuration, and change management, charge for those inputs.
Pure SaaS is not automatically the safer bet. It can reduce delivery labour, but it can also concentrate risk in product adoption, retention, distribution, and a small engineering team. A services business has a different weakness: revenue depends on people. Neither model gets a free pass.
New Zealand's technology economy shows the broader context. MBIE says digital technologies contributed $7 billion to GDP in 2021 and grew at 10.4% annually since 2016, compared with 5.1% annual growth for the wider economy, according to its digital technologies sector overview. The same overview reported SaaS revenue at $2.2 billion in 2021, growing at about 16% per year.
That growth makes SaaS attractive, but it doesn't erase local constraints. The kiwiSaaS 2024 State of the Nation report estimated $3.6 billion in SaaS revenue in 2023, with export-led added value contributing $2.2 billion to GDP in the previous year. It also reported that the top 10% of SaaS companies generated 68% of sector revenue. That is a strong export story and a clear warning about concentration.
A founder can escape project work and still end up dependent on one enterprise logo. If one customer becomes a large share of revenue, the business carries a different version of the same danger. Product revenue doesn't make concentration disappear.
Pure product teams also need enough engineering, product, security, design, and customer capability to keep moving. NZ's talent pool is not infinite, and founders often need revenue before the product is fully mature. Services can fund the team through the slow build, provided the founders protect product time and don't allow every client request to become a custom branch.
MBIE has described a possible path where SaaS grows at 19% annually, reaching nearly $14 billion by 2030 and creating as many as 58,000 jobs, but that outcome depends on finding enough talent, as noted in its export success focus area. The implication for a founder is practical: don't assume hiring will solve a delivery problem later.
The right model is the one that turns your first customers into learning, cash, and repeatable delivery at the same time.
A hybrid model can be more honest. Charge for implementation. Keep the core product consistent. Document the work that repeats. Push customers towards standard workflows, but don't pretend every buyer can self-serve from day one.
That is the contrarian point. The best answer isn't SaaS versus non-SaaS. It's the delivery mix that matches your first ten customers, your hiring runway, and your export thesis.
Don't spend another month debating labels. Write one sentence for each question below, then choose the model that matches the evidence.
Available capital
How much runway do you have before revenue must carry the business?
If runway is short, lean services or hybrid. If funding is strong and product risk is understood, lean SaaS.
Time to first dollar
How quickly can a real customer pay for a useful outcome?
A paid project or implementation points towards services. A repeatable product with early demand supports SaaS.
Sales motion
Will customers buy without a founder-led conversation?
If yes, lean SaaS. If every sale needs workshops, procurement support, and trust-building, lean hybrid.
Delivery cost
What work must your team complete after the contract is signed?
Low marginal effort favours SaaS. Heavy configuration, training, and integration favour services or hybrid pricing.
Growth ceiling
Can revenue grow faster than headcount?
If the product can serve more customers without matching labour growth, lean SaaS. If people remain central to delivery, price as a service.
Churn tolerance
How much customer loss can the business absorb while it learns?
A narrow market and high switching risk call for paid onboarding and close account support. A clear, repeatable use case can support a more product-led approach.
Hybrid potential
Which customer services could become standard modules, playbooks, or workflows?
If the answer is several, start hybrid and gradually move repeatable work into the product.
Cloud adoption supports the product side of the argument. NZ cloud spending was forecast to rise from NZD 1.7 billion in 2020 to NZD 3.5 billion in 2024, with SaaS close to 60% of public-cloud spending, according to the Microsoft public cloud opportunities report. IDC later forecast New Zealand public-cloud spending rising from NZ$5 billion in 2024 to NZ$9.6 billion in 2028, an implied four-year CAGR of 18%, in its New Zealand State of Cloud report. Cloud is useful infrastructure, but it doesn't decide your pricing or delivery model for you.
My recommendation is direct. Most New Zealand founders below $5M ARR should default to a hybrid software-plus-services model unless they already have overseas distribution or have raised capital specifically for a pure-product bet. Build the repeatable core, charge for the work around it, and use each customer to make delivery less bespoke.
If you're shaping that model, NZ Apps offers regional company coverage, app and software directories, and practical guides for founders evaluating product, compliance, and growth decisions. Visit NZ Apps to review the local market and position your software or services business for NZ and AU buyers.
Add your NZ or Australian app or tech company to the NZ Apps directory and get discovered by founders and operators across the region.
Get ListedReach tech decision-makers across New Zealand and Australia. Sponsored and dofollow editorial links, permanent featured listings, and sponsored articles on a DA30+ .co.nz domain.
See Options