# Build the capability. Keep control of what belongs to you.

> An engineering engagement should not end in a black box. The client needs a clear record of what was created, what they own, what remains licensed and what it takes to operate or extend the system.

Canonical URL: https://marmation.com/approach/client-ownership/

## The decision

Could another team take over without guesswork?

Source transfer is only part of control. Agree what is assigned, what remains licensed, where access lives and how a new engineer will prove the system can be built, deployed and operated.

## The situation behind the request

A company commissions a custom internal application. It expects its developers to maintain and extend it using their own tools. The build used third-party model APIs, a cloud provider, commercial packages and generated code.

## Where the obvious solution falls short

“You own everything” is often inaccurate. Bespoke source and assigned IP may be owned under contract, but external services and licensed components remain governed by their own terms. Access to source without deployment documentation is incomplete handover.

## How we would approach the work

Define ownership in the statement of work, maintain a dependency register, use agreed repositories and establish delivery artifacts. Include architecture, local/deployment instructions, access roles, tests, known limitations and operating runbooks.

## What the engagement may include

- Clear IP assignment boundaries for custom deliverables.
- Client-repository/source transfer where contracted.
- Architecture, test, deployment and operational documentation.
- Third-party licensing, cloud and usage register; optional support scope.

## The choices worth making explicitly

Some projects legitimately depend on Salesforce, Azure or other licensed platforms. Ownership should not be confused with avoiding all subscriptions. The goal is to make dependencies explicit and controllable.

## What we would test before calling it ready

Verify handover using a second engineer or client team member who can build and deploy from the documents. Record gaps and responsibilities for maintenance.

## A sensible first step

Discuss the desired ownership and operating model at the architecture stage, not after deployment.

## Related reading

- [Clarity before code. Accountability through delivery.](https://marmation.com/approach/)
- [Start with the right size of commitment.](https://marmation.com/engagements/)
- [A reliable system is designed for more than the ideal case.](https://marmation.com/approach/engineering-quality/)