Scope of Work Clauses for New Zealand Health App Development Agreements

If you are paying a developer to build a health app, the scope of work clause is where the deal usually goes right or wrong. New Zealand founders often make the same mistakes: they describe the product too loosely, assume privacy and security work is already included, or rely on verbal promises about integrations, clinical features, and deadlines. Those gaps can lead to budget blowouts, delays, arguments about whether the app is finished, and serious problems if the app handles health information.

A well-drafted scope of work does more than list features. It sets the boundaries of the project, explains what the developer must deliver, and allocates responsibility for testing, compliance-related work, third party services, and post-launch fixes. For health apps, that matters even more because software choices can affect privacy, data handling, user safety, and marketing claims.

This guide explains what scope of work clauses for health app projects should cover for New Zealand businesses, what legal issues to check before you sign, and the drafting mistakes that commonly catch founders out.

Overview

The scope of work clause should tell both sides exactly what is being built, how success is measured, and what sits outside the agreed price. For a health app project in New Zealand, that clause also needs to address privacy-sensitive functionality, third party integrations, testing standards, and who carries responsibility for compliance-related inputs.

• Define the app features, platforms, user roles, and excluded items in detail.
• State who is responsible for privacy, security, clinical content, and regulatory assumptions.
• Set clear milestones, acceptance criteria, testing obligations, and sign-off steps.
• Deal with change requests, overruns, delays, and dependencies on your team or third parties.
• Clarify ownership of code, data, content, designs, and licensed components.
• Specify support, maintenance, bug fixes, and service levels after delivery.

What Scope of Work Clauses for Health App Means For New Zealand Businesses

A scope of work clause is the part of the development agreement that defines the job. Before you sign a contract, it should tell you what the developer is actually building, what standard it must meet, what assumptions the price depends on, and what work will cost extra.

For a general business app, a vague description is risky. For a health app, it is often much worse. The software may collect sensitive information, produce prompts or recommendations that users rely on, connect with wearable devices, or support clinical workflows. That means a loose scope can turn into a legal and commercial problem very quickly.

Why health app projects need more precision

Health app development agreements often sit at the intersection of software, data handling, and health-related claims. A founder may assume the developer will build secure storage, consent flows, role-based access, audit logs, and API connections as part of the base price. The developer may assume they are only coding what has been expressly specified.

That mismatch is where founders often get caught. If the scope says only “build a patient booking and wellness tracking app”, you still do not know:

• whether the app includes clinician and patient dashboards
• whether data is encrypted at rest and in transit
• whether the app includes identity verification or multifactor authentication
• whether push notifications can contain health information
• whether integrations with practice management software are included
• whether analytics tools can be used on sensitive screens
• whether the app must work offline or only with live internet access

Each of those points affects cost, timing, risk, and compliance.

What a good scope clause usually covers

A useful scope of work clause is specific enough that an outsider can read it and understand what will be delivered. Before you accept the provider's standard terms, the clause should usually cover:

• project objectives and intended use case
• target users, such as patients, clinicians, admins, or support staff
• supported platforms, such as iOS, Android, web app, or tablet use
• feature list, workflows, and business rules
• design deliverables and the number of revision rounds
• integration work with third party systems, devices, payment tools, or messaging providers
• data migration, import, or export requirements
• privacy and security features to be built into the product
• testing, user acceptance testing, defect categories, and remediation windows
• documentation, training, handover, and deployment support
• post-delivery support, maintenance, and version updates
• items expressly excluded from the scope

This level of detail protects both sides. It gives the developer a clear brief and gives your business a practical benchmark for payment and sign-off.

How New Zealand context changes the drafting

New Zealand businesses developing health apps should take a local view of privacy and advertising risk. If the app will collect personal information, especially health information, your agreement should not casually assume those issues can be sorted later. The Privacy Act 2020, along with the Health Information Privacy Code where relevant, can shape how data collection, access, storage, disclosure, and correction rights are handled in practice.

The scope does not need to reproduce every legal obligation. It does need to state who is responsible for building the relevant functionality and who is responsible for supplying lawful content, policies, consent wording, and business rules, including any privacy notice.

Marketing and in-app claims matter too. If the app suggests health outcomes, symptom support, wellbeing benefits, or clinical usefulness, the business still needs to think about fair trading and misleading representations. A developer is not usually responsible for the truth of your claims unless the contract says otherwise. The scope should make it clear whether the developer is simply implementing your content or also advising on product logic and user messaging.

Legal Issues To Check Before You Sign

Before you sign, make sure the scope of work clause matches the real project, not just the sales pitch. The main legal risk is not only poor drafting, it is a contract that leaves key assumptions unstated.

1. Feature definitions and boundaries

The scope should describe the app at a level that can actually be tested. “User dashboard” is not enough. What data appears there, who can access it, what actions can be taken, and how many user types are included all matter.

If the health app includes multiple audiences, split the functionality by role. For example:

• patient registration and login
• practitioner account management
• appointment booking and calendar sync
• medication reminders and notification controls
• secure messaging
• telehealth or video consultation capability
• mood tracking, symptom logging, or wearable data import
• admin reporting and audit history

The contract should also list exclusions. If multilingual support, smartwatch integration, AI triage, or pharmacy connectivity are not included, say so clearly.

2. Privacy and health information handling

If your app handles health information, privacy design should be addressed in the scope, not buried in a later technical document. Before you rely on a verbal promise, confirm whether the developer must build:

• consent collection screens
• privacy settings and permissions management
• user access and correction tools
• role-based access controls
• encryption requirements
• retention and deletion functionality
• audit logs for access or edits
• data segregation if multiple clinics or organisations use the same app

You should also check where data will be hosted and whether the developer will use offshore subcontractors or infrastructure providers. Cross-border handling may raise extra questions, especially where the business promises local handling or has specific customer expectations.

3. Security obligations and standards

Security is often discussed broadly and documented poorly. A contract that says the developer will use “industry standard security” may be too vague to enforce if something goes wrong.

Ask for concrete obligations around:

• authentication methods
• password policies
• multifactor authentication where needed
• encryption in transit and at rest
• session timeouts
• logging and monitoring
• secure coding and vulnerability remediation
• penetration testing or third party security review, if required

If the developer will process information on your behalf, the agreement may also need stronger confidentiality and data protection clauses alongside the scope.

4. Clinical content and decision-making assumptions

Health apps can blur the line between wellness support and clinical guidance. The scope should say whether the developer is merely implementing content you provide or helping design logic that affects recommendations, alerts, or risk scoring.

This matters because responsibility should be allocated clearly. Your business may need to warrant that clinical content, treatment pathways, escalation rules, and disclaimers have been reviewed by suitable subject matter experts. The developer may agree to code those rules accurately, but not to validate their medical accuracy.

5. Milestones, acceptance testing, and sign-off

A development project becomes hard to manage when invoices are tied to broad stages like “build complete”. Before you spend money on setup or later phases, make sure each milestone has objective acceptance criteria.

Good acceptance language usually addresses:

• what is delivered at each stage
• how long you have to review it
• what counts as a defect
• which defects must be fixed before acceptance
• what happens if you do not respond on time
• whether partial acceptance is allowed
• when final sign-off occurs

This is especially important where the app will be piloted with clinics, providers, or a limited user group before broader release.

6. Change requests and scope creep

Health app projects change as founders see demos, clinicians give feedback, and privacy concerns emerge. A good scope of work clause accepts that change will happen and sets a process for dealing with it.

Your agreement should explain:

• how changes are requested
• who approves them
• when the developer must provide price and timing impacts
• whether urgent compliance or security fixes are handled differently
• what work can proceed without a signed variation, if any

Without this, disagreements often arise over whether a requested item is a defect fix, an assumed requirement, or a paid variation.

7. Third party tools, integrations, and dependencies

Many health apps rely on external services such as SMS tools, payment gateways, video platforms, cloud hosting, analytics products, wearable APIs, or practice management software. The scope should identify those dependencies and who is responsible for obtaining them.

Check for these questions:

• Who pays third party licence fees?
• Who secures integration access and technical documentation?
• What happens if a third party changes its API or approval process?
• Is the developer responsible for configuring the service or only connecting to it?
• Are there limits on supported versions, devices, or browsers?

For New Zealand businesses, this also matters where a clinic or enterprise customer requires specific hosting, messaging, or procurement arrangements.

8. Intellectual property ownership

Before you sign, make sure the contract states who owns the app code, designs, workflows, documentation, and custom content. Many founders assume that paying for development means they own everything. That is not always the default position under the contract.

The agreement should distinguish between:

• new custom materials created for your project
• the developer's pre-existing tools, frameworks, and know-how
• open source components
• third party licensed software
• your business data, branding, and content

If ownership is not transferred in full, at minimum you may need a broad ongoing licence to use, maintain, and modify the app.

9. Support, maintenance, and live issues

The scope for initial development is only part of the picture. Health apps often need bug fixes, OS updates, server support, and security patches after delivery. If this work is important, it should not be left to informal discussions at the end of the project.

Spell out whether post-launch support includes:

• response times for critical issues
• maintenance hours or support caps
• security patching
• compatibility updates for iOS or Android changes
• backup and recovery obligations
• service availability commitments, if hosting is included

Common Mistakes With Scope of Work Clauses for Health App

The most common mistake is assuming everyone shares the same picture of the finished product. Before you sign, turn assumptions into written terms.

Using broad labels instead of detailed functionality

Terms like “HIPAA-style security”, “patient portal”, or “wellness dashboard” sound useful but often hide disagreement. In New Zealand contracts, plain descriptions of actual functionality usually work better than labels borrowed from overseas or sales material.

If a feature matters, describe what it does. If a security control matters, identify it specifically.

Leaving privacy work outside the build scope

Founders sometimes treat privacy compliance as a policy issue only. For health apps, many privacy outcomes depend on product design. If the app needs user permissions, correction rights, segregation of records, secure messaging controls, or deletion workflows, that work must appear in the scope and price.

Failing to allocate responsibility for content and clinical logic

Developers can build what you ask for, but they are not automatically responsible for deciding whether symptom pathways, alerts, educational content, or recommended actions are clinically suitable. If your app includes treatment support, triage prompts, or personalised health suggestions, the contract should allocate review responsibility carefully.

Not documenting assumptions about timing

A developer's timeline often depends on your team supplying content, approvals, access credentials, or testing feedback by certain dates. If those dependencies are not written down, each delay can become a dispute about who caused it.

The scope should state client responsibilities, including:

• providing branding, content, and policy text
• reviewing designs and builds on time
• arranging access to third party systems
• supplying subject matter expert feedback
• appointing a decision-maker for sign-off

Accepting a vague variation process

When the project changes, a messy variation process can be as damaging as a vague original scope. Founders often ask for “small” changes during the build that later appear as large extra charges. A written process protects your budget and gives the developer a fair mechanism for adjusting price and delivery dates.

Ignoring ownership and exit rights

Some businesses only check IP ownership when the relationship breaks down. That is too late. If you want to move the project to another developer later, you may need access to source code, repositories, technical documents, credentials, and deployment instructions. The contract should say what handover materials must be provided and when.

Treating compliance as the developer's problem alone

A developer can agree to build required functionality, but your business still needs to make decisions about lawful collection, notices, content accuracy, and operational processes. Founders sometimes sign a development agreement as though it transfers all compliance responsibility. It usually does not.

That is why the scope should work alongside the rest of the contract, including privacy obligations, warranties, liability clauses, confidentiality, and any statement of client responsibilities.

FAQs

Do scope of work clauses for a health app need to mention privacy specifically?

Yes, if the app will collect or handle health information, the scope should identify the privacy-related functionality the developer must build. General wording is usually not enough where user permissions, access controls, deletion functions, or audit history matter.

Can we rely on proposal documents and email discussions instead of a detailed contract clause?

You can refer to proposals or technical schedules, but the signed agreement should clearly incorporate them and say which document takes priority if there is inconsistency. Verbal promises and scattered email statements are much harder to enforce.

Who should own the code for a custom health app?

That depends on the commercial deal. Many businesses want ownership of custom code and a licence back for the developer's pre-existing tools. Others accept a broad licence arrangement. The key point is to state it clearly before you sign.

Should acceptance testing be different for a health app?

Often yes. A health app may need more detailed testing for user roles, privacy settings, integrations, notification behaviour, and data handling than a simple marketing app. The contract should describe how testing works and what defects must be fixed before acceptance.

What happens if we need new features halfway through development?

The agreement should include a change request process covering approval, price impact, and revised timeframes. Without that process, it becomes difficult to tell whether added work is included, excluded, or chargeable as a variation.

Key Takeaways

• A scope of work clause should define exactly what your health app developer will deliver, what is excluded, and how completion is measured.
• For New Zealand businesses, privacy, health information handling, security controls, and responsibility for clinical content should be addressed expressly, not assumed.
• Clear milestones, acceptance testing, and change request procedures help prevent budget overruns and disputes about whether the work is finished.
• You should also check ownership of code and materials, third party integrations, hosting assumptions, and post-launch support obligations before you sign.
• The safest approach is to make the contract match the real project detail, especially before you accept the provider's standard terms or rely on verbal assurances.

If you want help with development agreements, privacy obligations, intellectual property ownership, and change request terms, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.