IP & Exit

Plain-English ownership, handover, and exit principles.

Initial scope determines cost. Final handoff includes the documentation pack and exit strategy. IP transfer happens at the agreed handoff point. Ongoing support is optional. This page sets out the plain-English position behind that delivery model.

At a glance

The key points, without the noise.

Scope Sets Cost

The initial agreed project scope determines delivery cost.

Handoff Includes Docs

Customers receive the project documentation pack, including the exit strategy document.

IP At Final Handoff

Where IP transfer or assignment applies, it is completed at final handoff or under the agreed contract position.

Support Is Optional

Support tiers are not mandatory and can be added later if the delivered system remains substantially unchanged.

Direct Support Depends On Tier

End users can request support directly from IATRT where the selected support tier includes it.

No Lock-In

Customers can pause or leave at any time. There are no lock-in contract periods.

Default position

Designed to reduce lock-in, not create it.

IP

Project IP

For development engagements, the public default position is customer-owned project IP, subject to the signed terms and any third-party licensing constraints. If assignment or transfer applies, it is completed at final handoff or under the already-agreed contract position.

FILES

Handover Artefacts

At delivery, customers receive the documentation relevant to the job. That can include repositories, schematics, PCB files, BOMs, configuration exports, operating notes, and an exit strategy document.

ACCESS

Systems & Credentials

Projects use a proper repository and file structure so handoff is straightforward. Customer-controlled environments should have clear admin access, documented dependencies, and a workable path for future support or migration.

EXIT

Transition Readiness

Exit should be practical: known artefacts, known services, known access paths, and a defined transition process with no hidden caveats. Customers can continue with IATRT, pause support, or move to another maintainer.

Commercial clarity

How scope, handoff, and optional support are surfaced.

Initial Scope & Cost

  • Initial project scope determines the delivery cost
  • Scope assumptions should be visible as early as practical
  • Repair, staged upgrade, and redesign are weighed against full replacement where relevant

Variations

  • Scope shifts are identified and explained rather than silently absorbed into the bill
  • Additional chargeable work should be approved before major out-of-scope effort proceeds
  • There are no hidden commercial caveats buried behind generic marketing copy

Final Handoff

  • Final handoff follows agreed testing and payment finalisation
  • The customer receives the project documentation pack, including the exit strategy document
  • If IP transfer is part of the project, it is completed at handoff or under the already-agreed terms

Optional Support

  • Support tiers are optional and can be added after delivery
  • They mainly apply where IATRT manages hosting, domains, ongoing hardware support, or other operational care
  • Customers can pause or leave at any time. There are no lock-in contract periods.

What customers should expect to receive

Exact artefacts depend on the job, but the objective is straightforward: after agreed testing and final payment, the customer should leave with the material needed to understand what was delivered, how it runs, how it can be supported, and how it can be handed over cleanly.

  • Scope summary, assumptions, and any approved variations
  • Repository or file structure used for the project where applicable
  • Source or configuration repositories where applicable
  • Design files and manufacturing data where relevant to the engagement
  • As-built notes, diagrams, labels, or network maps as appropriate
  • Access and credential handover steps for customer-owned systems
  • Exit strategy documentation as part of the delivery pack
  • Outstanding risks, dependencies, and recommended next actions

Support after delivery

Support tiers are optional. They are mainly for environments where IATRT continues to manage domains, hosting, ongoing hardware support, monitoring, or similar operational responsibilities. End users can request support directly from IATRT where the selected support tier allows it.

Customers can also return later and purchase support after delivery, provided the delivered system remains substantially as handed over and has not already been taken over by another maintainer.

Frequently Asked

When does IP transfer happen?

Initial project scope determines cost. After agreed testing is complete and final payment is settled, final handoff is completed with the project documentation pack. If IP assignment or transfer is part of the project, it happens at that handoff or under the already-agreed contract position. Third-party licensed components keep their own licence conditions.

What is included in the handoff pack?

It depends on the project, but the intent is straightforward: clear repo or file structure, relevant source and design artefacts, as-built notes, access handover information, and an exit strategy document so the customer is not left guessing how the system should be maintained or transferred later.

Are support tiers mandatory after delivery?

No. Support tiers are optional. They are mainly used where IATRT continues to manage hosting, domains, ongoing hardware support, or similar operational work. End users can request support directly from IATRT where the selected support tier includes it, but customers can pause or leave at any time and there are no lock-in contract periods.

Can we add support later or move to another maintainer?

Yes. The delivery model is meant to allow maintenance and migration, not trap clients. Support can be added later if the delivered system remains substantially as handed over and has not already moved to another maintainer. Clients can also transition support to an internal team or another provider when needed.

How do you handle underestimated scope or variations?

The stated approach is to surface the change early, explain the technical reason, and obtain approval before substantial out-of-scope work continues. That keeps the commercial mechanism visible instead of turning it into a surprise after the fact.

Related pages

Ownership works best when delivery and support are equally clear.

Delivery Framework

See how scoping, build, testing, handover, and best-fit project positioning are described publicly.

View framework

Support Tiers

See how retained support, onboarding, and proactive maintenance are structured.

View support tiers

Trust Pack

Review security, testing, and commercial notes that sit alongside ownership and exit expectations.

View trust pack

Contact

Address
4/143 Coonawarra Rd
Winnellie NT 0820

Phone
0410 152 013

Email
inquiries@iatrt.com

Service hours
Monday-Saturday
8:00am - 7:00pm
Closed Sundays & public holidays

Consultations

Free consultation by phone or at our Winnellie workshop. On-site callouts are available as paid services. We use the initial discussion to confirm scope, ownership expectations, and the most practical next step.

If the engagement proceeds, ownership and handover expectations should be reflected clearly in the proposal and contract.