Intellectual Property and Source-Code Ownership
When you pay for custom software, you should own it. This page sets out exactly what transfers to you when a Timeline Digital project completes, what we keep, how open-source licensing is handled, and how the handover itself works, so your procurement and legal teams can see the position before the first call.
The short version
- Delivered source code and project-specific IP transfer to you on full payment
- Repositories, credentials and documentation are handed over, not withheld
- We retain only generic internal tooling and general know-how
- Open-source components stay under their own licenses, fully documented
- Your team or another vendor can take over at any point after handover
What transfers to you when the project completes?
Everything created specifically for your project. The test we apply is simple: if it exists because of your engagement, it is yours.
Source code, complete and buildable
The full, uncompiled source of everything written for your project. Not a binary, not an export, the actual code your next team will read, build and change.
Repositories with full history
Git repositories transferred to your organization or pushed to your own git host, including the complete commit history, branches and release tags.
Designs and visual assets
UI designs, wireframes, design files and graphic assets created specifically for your project, in their editable source formats where they exist.
Documentation
Architecture notes, deployment guides, environment configuration, API references and operational runbooks written during delivery.
Infrastructure and accounts
Cloud accounts, domains, databases and third-party service accounts set up in your name from the start, or transferred into it, with credentials rotated at handover.
Your data, always yours
Business data entered into or processed by the system is your property from day one. It never needed to transfer, because it was never ours.
Who owns what after handover?
The same position, laid out item by item. Contracts state this formally; the table is the plain-English version.
| Item | Ownership after handover | What that means in practice |
|---|---|---|
| Custom application source code | You | Written for your project, transfers on full payment |
| Project repositories and commit history | You | Transferred to your git organization or host |
| UI designs, wireframes and project assets | You | Delivered in editable source formats where they exist |
| Technical documentation and runbooks | You | Part of the standard handover package |
| Cloud accounts, domains and databases | You | Held in your name, credentials rotated at handover |
| Your business data | You | Yours from day one, never a transfer item |
| Timeline Digital generic tooling and scaffolding | Timeline Digital | Pre-existing internal tools, not specific to your project |
| Open-source libraries and frameworks | Their own licenses | Documented in a dependency manifest you receive |
What does Timeline Digital retain?
An honest answer, because a vendor that claims to transfer everything is not describing how software is actually built.
Generic internal tooling
Project scaffolding, deployment scripts, code generators and internal utility libraries that existed before your project or were built outside it. These make delivery faster and keep pricing sensible across clients. Where a shared internal utility ships inside your codebase, it is delivered with the rest of the source, and you can keep using and modifying it as part of your system.
General know-how and experience
Our engineers keep the general skills, patterns and lessons they learn on every project. No contract can transfer experience out of people's heads, and no serious vendor will pretend otherwise. What the contract does protect is the specific: your business logic, your data, your designs and your code are not carried into other client work.
Nothing that locks you in
The retained items are inputs to how we work, not components your system depends on us to run. After handover there is no license fee owed to Timeline Digital, no proprietary runtime we host on your behalf, and no technical switch we can turn off. If a specific retained element matters to your review, we will name it in the contract rather than leave it vague.
How are open-source components handled?
Modern software is built on open source, and pretending otherwise helps nobody. Our commitment is transparency, not impossible ownership claims.
Their licenses stay in force
Open-source libraries and frameworks remain under their own licenses. No vendor can sell you ownership of React, PostgreSQL or a utility library it did not write, and any contract that implies otherwise should worry you. What transfers is your code that uses them.
A manifest you can audit
The handover package includes a dependency manifest: every third-party library in the system and the license it carries. Your legal or compliance team can review it during the project, not just at acceptance, and raise any component they are not comfortable with.
Deliberate license choices
For commercial work we prefer permissively licensed components such as MIT, Apache 2.0 and BSD. Copyleft licenses like the GPL carry obligations that affect how you can distribute the system, so any such component is flagged and agreed with you before it enters the codebase.
The delivery record behind these terms
Ownership language only matters if the company offering it actually completes projects and hands them over. Ours has been doing that for over a decade.
2013
Founded, delivering ever since
1,500+
Projects delivered
860+
Active clients
25+
Countries served
Delivery capacity: 1,200+ developers and 85+ management professionals, counted as direct and group-company employees.
What does the handover process look like?
Handover is a defined stage of every project, with its own checklist. These are the five steps, in the order they happen.
01
Repository transfer
Repositories move to your git organization, or we push the full history to a host you control. You hold the code on your own infrastructure, not a copy that lives with us.
02
Credentials and accounts
Cloud, domain, database and third-party service accounts are transferred into your name or confirmed as already there. Secrets are inventoried and rotated so old credentials stop working.
03
Documentation package
You receive the architecture overview, deployment and environment guides, operational runbooks and a dependency manifest listing every third-party library with its license.
04
Walkthrough sessions
The engineers who built the system walk your team, or your incoming vendor, through the codebase, deployment flow and known trade-offs. Sessions can be recorded for later reference.
05
Verification build
Your side builds and deploys the system from its own copy of the code. Handover is complete when that works without us, not when files arrive in an inbox.
The standard we hold ourselves to
Handover is finished when your side can build, deploy and change the system without us in the room. Anything short of that is a delivery, not a handover.
What shapes handover effort and timing?
There is no single answer that fits every system, so here are the factors that actually move the needle, stated plainly.
Timeline factors
Handover effort depends on system size, the number of environments, and how involved your team has been during delivery. Teams that held repository access throughout need far less transition time than teams receiving everything at once.
Cost factors
A documented handover of the delivered system is part of the project, not an extra invoice. Extended training programs or long parallel-running periods are scoped separately, and what they cost depends on how deep you want them to go.
Client involvement
You name the people or vendor receiving the system, provide or approve the git host and cloud accounts it will live in, and put the right people in the walkthrough sessions. Handover to an empty chair does not work.
Risks to manage
The classic failures are credentials left in vendor-owned accounts, undocumented dependencies, and skipping the verification build. Our process exists to close each of these before the engagement ends.
Can we arrange escrow or continuity protections?
Yes. For organizations whose risk or governance requirements go beyond standard terms, these arrangements can be discussed and written into the contract during scoping.
Client-owned repositories from day one
Often the strongest protection available: work is committed to repositories your organization owns from the first sprint, so there is never a moment when you do not hold the current code.
Source-code escrow
For organizations whose governance requires it, code can be deposited with an escrow agent under agreed release conditions, such as insolvency or failure to support. The agent, deposit schedule and conditions are set in the contract.
Contractual documentation standards
Documentation and handover obligations can be written into the agreement as deliverables in their own right, so they are acceptance criteria rather than good intentions.
Milestone-aligned payments
Payments can be structured against delivered, reviewable artifacts, which keeps ownership and payment moving together and avoids a single all-or-nothing moment at the end.
None of these are exotic requests, and raising them does not signal distrust. Bring them up in the first scoping conversation and they become normal contract clauses rather than late-stage negotiations.
Why does ownership matter in procurement?
Because the cost of weak ownership terms arrives years after the contract is signed, when it is hardest to fix.
Terms of this kind have carried our public-sector delivery too, including a public-sector program in Qatar, where ownership and continuity requirements are non-negotiable parts of procurement.
Vendor lock-in is a pricing problem
A vendor that controls your source code controls your renewal price. Every maintenance quote, change request and support contract is negotiated without a credible alternative, because moving away would mean rebuilding. Ownership restores your ability to tender maintenance competitively.
Continuity risk is real, and boring, until it is not
Vendors get acquired, pivot, or close. If your system lives only in their infrastructure and their repositories, their corporate events become your operational emergencies. Code, credentials and documentation in your own hands turn that scenario into an inconvenience.
Audits and compliance need access
Security reviews, regulatory audits and due-diligence exercises all eventually ask to see the code and its dependencies. Ownership with a documented dependency manifest means you can answer those requests without asking a vendor's permission.
Ask every vendor the same questions
Who owns the code, and when? What exactly is handed over? What happens if we part ways early? Put the answers in the contract, not in emails. This page is our set of answers; we are comfortable being compared on them. Discuss your software requirements with Timeline Digital.
Ownership and Handover Questions
The questions legal, procurement and technical reviewers ask most, answered directly.
Ownership follows the contract, and our standard terms are written so that paid work transfers. If an engagement ends before completion, the source code and project materials produced for the milestones you have paid for are handed over in their current state, with an honest note on what is finished and what is not. We do not hold completed, paid-for work back to force a continuation. The practical caveat is that partially built software may not run without further work, so we document its exact state at handover so your next team knows where things stand.
Yes, and the handover is designed for exactly that. Your team receives the full source code with commit history, environment and deployment documentation, a dependency manifest, and walkthrough sessions with the engineers who built the system. Many clients run a transition period in which their developers ship changes alongside ours before taking over fully. There is no proprietary runtime or hidden service that stops the system from working once we step away, and you can bring in another vendor on the same material if you prefer.
Open-source components remain under their own licenses, because no vendor can transfer ownership of code it does not own. What we do is choose dependencies deliberately, prefer permissive licenses such as MIT, Apache 2.0 and BSD for commercial work, flag any copyleft component before it enters the codebase, and hand over a dependency manifest listing each library and its license. Your legal or compliance team can review that manifest at any point during the project, not only at the end.
No. Code, designs and documents created specifically for your project are your intellectual property and are not resold or reused in other client systems. What carries between projects is generic: our internal tooling, project scaffolding and the general experience of our engineers. That separation is written into our contracts. If your project involves sensitive business logic, an NDA covers the engagement from the first requirements discussion, and additional confidentiality terms can be agreed where your industry requires them.
A complete handover covers the source code repositories with full history, credentials and accounts transferred into your name with secrets rotated, technical documentation covering architecture, deployment and operations, a dependency manifest with licenses, and walkthrough sessions for your team or your next vendor, recorded where useful. We treat handover as complete when your side has built and deployed the system from its own copy of the code, not when a set of files lands in an inbox.
Yes. Most clients have repository access throughout delivery, so review is continuous rather than a single event at the end. You, or a third-party reviewer you appoint, can read the code, run static analysis and check dependencies while the project is in flight. If your procurement process requires a formal pre-acceptance audit, we schedule it as a milestone before final payment. We would rather have issues surfaced while the team that wrote the code is still on hand to fix them.
Tell us your problem. Get a clear plan and price.
Describe what is slowing your business down. On a free call we will tell you what to build, how long it takes and what it costs.
- A senior specialist joins the conversation
- NDA available before sensitive details are shared
- Written next steps and suitable delivery options