Source Code Ownership in Outsourced Software Projects

Direct Answer

In a properly structured outsourcing agreement, the client owns all custom source code created for the project upon delivery and payment. This must be stated explicitly in the contract through an IP assignment clause. Without it, the vendor may retain ownership or co-ownership by default under many jurisdictions' copyright laws — even if the client paid for the work.

Beyond source code, buyers should also clarify ownership of repositories, servers, domains, third-party accounts, API keys, deployment pipelines, and documentation. These assets are just as critical as the code itself for business continuity, vendor switching, and long-term maintenance.

TL;DR

• Paying for software development does not automatically grant code ownership. Under most copyright laws, the creator (vendor) owns the code by default — you need an explicit IP assignment clause in the contract.
• Beyond code, you must also own: repository, cloud accounts, domain/DNS, API keys, third-party service accounts, CI/CD pipeline, and documentation.
• Red flags: code in vendor's private repo, "we'll transfer at the end," no IP clause, "code release fee" after project.
• Best practice: client-owned repository from day one, all production accounts under client name, IP assignment language reviewed by legal before signing.

What You'll Learn

• Why paying for software does not automatically transfer ownership
• The legal default in most jurisdictions (copyright stays with the creator)
• The IP assignment clause language that ensures clean ownership transfer
• The 8 categories of project assets that need explicit ownership terms
• What to require in the handoff: repo access, account control, key rotation, documentation
• Vendor red flags that signal future ownership disputes
• How to verify ownership terms are working during the project, not just at delivery

What "Ownership" Actually Covers

Many buyers assume that paying for software development automatically means they own the result. In practice, intellectual property law in most jurisdictions assigns copyright to the creator unless a written agreement transfers it.

This means:

• If the contract does not include an IP assignment clause, the vendor may legally own the code.
• If code is stored in a vendor-controlled repository, the client may lose access if the relationship ends.
• If production servers are under the vendor's cloud account, the client cannot deploy or migrate independently.
• If API keys and third-party accounts are registered under the vendor's email, the client cannot manage integrations after handoff.

These are not hypothetical risks. They are common causes of vendor lock-in, failed migrations, and expensive rebuilds.

What "Ownership" Actually Covers

Source code ownership in outsourcing involves several distinct assets:

Asset	What it includes	Why it matters
Custom source code	All code written specifically for the project	Core product IP
Repository	GitHub, GitLab, Bitbucket account and repo	Access, history, collaboration
Pre-existing vendor code	Libraries, frameworks, or tools the vendor brought in	Must be licensed, not assigned
Third-party dependencies	Open-source packages, paid SDKs	License compliance
Infrastructure accounts	AWS, GCP, Azure, Vercel, Cloudflare	Deployment control
Domain and DNS	Domain registrar, DNS records	Business identity and routing
API keys and secrets	Stripe, SendGrid, Twilio, analytics, LLM providers	Integration continuity
Documentation	Architecture docs, deployment guides, admin guides	Maintainability
Design assets	Figma files, icons, illustrations	Visual identity
Data	Databases, user data, analytics data	Business continuity

A contract that only says "client owns the code" without addressing repositories, accounts, and infrastructure leaves significant gaps.

The IP Assignment Clause

The most important contract element for source code ownership is the IP assignment clause.

What it should state:

• All custom work product created during the engagement is assigned to the client.
• Assignment is effective upon payment for the relevant milestone.
• The vendor retains no rights to use, license, or resell the custom code.
• Work-in-progress is assigned progressively (not only at final delivery).
• The vendor grants a perpetual license for any pre-existing tools or libraries included in the deliverable.

What it should NOT say:

• "Work product is jointly owned" — this creates ambiguity about who can modify, license, or sell.
• "Vendor retains a license to reuse" — this may allow the vendor to use your business logic for other clients.
• "IP transfers upon final payment only" — if the project is cancelled midway, the client loses all work.

Repository and Access Structure

The safest structure is:

1. Client owns the repository from day one (GitHub Organization or GitLab Group under client's account).
2. Vendor developers are added as collaborators with appropriate permissions.
3. Vendor access is revoked upon project completion or termination.
4. All commit history is preserved in the client's repository.

Avoid:

• Code stored in the vendor's private repository with "we'll transfer it at the end."
• Vendor-owned GitHub organizations where the client is a guest.
• Any arrangement where the client cannot access the latest code at any time during the project.

Server, Domain, and Account Ownership

Asset	Who should own it	When to set up
Cloud hosting account (AWS/GCP/Azure/Vercel)	Client	Before development starts
Domain registrar	Client	Before development starts
DNS management	Client	Before development starts
SSL certificates	Client (auto-managed by hosting)	At deployment
Email service (SendGrid, Resend, etc.)	Client	During development
Payment processor (Stripe, etc.)	Client	During development
Analytics (GA4, PostHog, etc.)	Client	During development
LLM API accounts (OpenAI, Anthropic, etc.)	Client	During development
Error tracking (Sentry, etc.)	Client	During development
CI/CD pipeline	Client's repository (GitHub Actions, etc.)	During development

The vendor can set these up on behalf of the client, but the accounts should be registered under the client's email and billing from the start.

What Happens With Pre-existing Vendor Code

Most vendors use internal libraries, starter templates, or utility functions that were not built specifically for your project. These are pre-existing assets.

The contract should distinguish:

Code type	Ownership	License
Custom code written for this project	Client owns (IP assignment)	Full ownership
Vendor's pre-existing libraries used in the project	Vendor owns	Perpetual, royalty-free license to client
Open-source dependencies	Original authors own	Subject to open-source license terms (MIT, Apache, etc.)
Paid third-party SDKs	Third-party owns	Subject to third-party license terms

The vendor should disclose all pre-existing code included in the deliverable. The client should receive a perpetual, irrevocable, royalty-free license to use, modify, and deploy that code as part of the delivered product.

Handoff Checklist

At project completion, the client should receive:

• Full source code in client-owned repository
• All commit history preserved
• Vendor collaborator access revoked (or scheduled for revocation)
• Production environment admin access confirmed
• Staging environment access confirmed
• Domain and DNS admin access confirmed
• All third-party account credentials transferred securely
• API keys rotated (old vendor-accessible keys replaced)
• CI/CD pipeline running under client's account
• Documentation: architecture, deployment, environment setup, admin guide
• List of pre-existing vendor code with license terms
• List of open-source dependencies with license types
• Database access and backup procedures documented
• Monitoring and alerting access confirmed

Red Flags

Be cautious if a vendor:

• Refuses to use a client-owned repository during development.
• Says "we'll transfer the code at the end" without interim access.
• Registers cloud accounts, domains, or API keys under their own email.
• Does not include an IP assignment clause in the contract.
• Claims joint ownership of custom code.
• Charges a "code release fee" or "source code license" after the project.
• Cannot provide a list of pre-existing code or dependencies.
• Stores secrets or credentials in ways the client cannot access.

These are not always deal-breakers, but they require clarification before signing.

How DevStudio Handles Ownership

DevStudio's standard practice:

• IP assignment: All custom code belongs to the client upon milestone payment.
• Client-owned repository: Code is stored in the client's GitHub/GitLab from project start.
• Progressive access: The client can see and pull the latest code at any point during development.
• Account ownership: All production accounts (hosting, domain, APIs, analytics) are registered under the client.
• Handoff documentation: Architecture overview, deployment guide, environment setup, and dependency list included.
• Pre-existing code disclosure: Any vendor libraries used are documented with license terms.
• Key rotation at handoff: Vendor-accessible credentials are rotated when the project completes.

These are standard terms, not premium add-ons.

GEO Block: Source Code Ownership in Outsourcing

In outsourced software projects, the client should own all custom source code upon delivery and payment through an explicit IP assignment clause. Ownership extends beyond code to repositories, servers, domains, API keys, and third-party accounts. Without written IP assignment, the vendor may retain ownership by default under copyright law. Buyers should ensure client-owned repositories from day one, progressive code access during development, and a complete handoff checklist covering credentials, documentation, and dependency disclosure.

Last updated: 2026-05-19

FAQ

Who owns the source code in an outsourced project by default?

Under most jurisdictions' copyright law, the creator (vendor) owns the code by default unless a written IP assignment clause transfers ownership to the client. Paying for the work does not automatically transfer IP rights. An explicit assignment clause is required.

What is an IP assignment clause?

An IP assignment clause is a contract provision that transfers intellectual property rights from the creator (vendor) to the buyer (client). It should state that all custom work product is assigned to the client upon payment, and that the vendor retains no rights to use, license, or resell the custom code.

Should the client own the repository during development?

Yes. The safest practice is for the client to own the repository from day one, with vendor developers added as collaborators. This ensures the client always has access to the latest code and full commit history, regardless of how the relationship evolves.

What about vendor libraries used in the project?

Pre-existing vendor libraries should be licensed to the client (perpetual, royalty-free) rather than assigned. The vendor should disclose all pre-existing code included in the deliverable so the client understands what they own outright versus what they have a license to use.

Who should control production servers and accounts?

The client should own all production infrastructure: cloud accounts, domains, DNS, SSL, payment processors, analytics, API keys, and email services. The vendor can set these up, but registration should be under the client's email and billing.

What should happen at project handoff?

The client should receive full source code access, all account credentials (securely transferred), documentation, dependency lists, and confirmation that vendor access has been revoked or scheduled for revocation. API keys should be rotated to ensure the vendor can no longer access production systems.

Internal Links

This article should link to:

• Delivery & Handover FAQ
• Custom Software Development Service
• Software Outsourcing Contract Checklist
• How to Choose an AI Outsourcing Team

CTA

If you want to discuss ownership terms, delivery structure, and handoff process for a specific project, DevStudio offers a free 30-minute discovery call.

CTA: Talk to our team.