What Should You Receive When Software Is Handed Over to Another Team?

This is a valid concern. We are a small studio, and we do not have client references showing a successful takeover of one of our projects by another supplier. We can show our own products, the technologies we use and our published handover terms. It would not be honest to promise that one person's absence could never cause complications.

The “bus factor” describes how dependent a project is on specific people. For a business owner, the important question is whether the code, operational accounts and knowledge needed to continue remain accessible when those people are unavailable. If an essential process exists only in someone's head, owning the files alone does not solve the problem.

Our process page lists a standard stack of Next.js, TypeScript and PostgreSQL, automated tests and CI, meaning automated checks on changes. Another team therefore does not need to learn a proprietary Iterus development tool. It will still need to understand the specific application, its rules and its dependencies.

We work AI-native: delivery is accelerated with Claude Code and Codex, and quality is secured by automated tests, independent code review and specialists on demand.

The development approach alone is not proof that a takeover will be easy. You get that proof only by testing the handover materials in practice. We also describe the scope of our work and handover here:

On our website, we state that the client owns 100% of the source code and documentation upon payment. Under our terms and conditions, this legally means the licence described below. Its scope is what matters when you want the option to change suppliers.

Once you pay the full price of the work or the delivered stage, you receive an exclusive licence to the copyright works created for you, with no limits on time, territory, quantity or manner of use. It covers modifications, combining the outputs with other works, granting sublicences and assigning the licence to other parties. We give our advance consent to assignment under the terms, and the licence fee is included in the price.

The terms also distinguish project outputs from third-party components. You use open-source libraries and other third-party components under their original licences, as listed in the handover inventory. General tools, processes and know-how that Iterus developed independently of the project remain with Iterus. The client receives a non-exclusive, perpetual licence to them to the extent needed to use the work.

The terms also cover parts of the output created entirely by automated means: the client receives all existing rights that Iterus can grant. Consult a lawyer when reviewing a specific contract or unclear licensing requirements. You can find the exact wording here:

Under our terms and conditions, we hand over the work or a project stage with the source code, documentation and an inventory of third-party components, including open-source licences. For a practical takeover, we recommend agreeing in advance on the exact contents of these materials. Treat the following points as a checklist for specifying the handover; the binding scope is set by the terms and conditions and the agreement for your project.

Source code in a repository. The repository stores both the files and their change history. At handover, it should be clear which version is running in production, where deployments originate and who can manage access. The incoming team needs to distinguish completed changes from work-in-progress branches.

Application and data documentation. Useful documentation explains the application's purpose, main parts, user roles and connections to other systems. It should include setup instructions and a description of database changes. It should also record known limitations and decisions whose reasoning cannot easily be inferred from the code.

Components and licences. The inventory should let the new team identify what the application depends on and which terms apply to those components. Besides libraries, it is practical to record paid services and their purpose. For every service, you need to know who manages the account and who pays the running costs.

Tests and automated checks. Having a folder called “tests” is not enough. The handover materials should explain how to run the tests, what test data they require and what the results mean. A green result does not mean the application has no defects; it means that the specific scenarios being checked have passed.

Deployment and operational access. The recommended scope covers building the application, configuring its environment, deployment, backups and recovery. Credentials belong in a secure handover process, not in ordinary repository documentation. What matters is verifying actual administrative access to the hosting, database, domain and connected services.

This framework is useful when commissioning a new application, not just during handover. It helps define what must be demonstrably ready when another team takes over.

We recommend testing the takeover in a separate environment. The incoming team receives the materials and access intended for the test, then follows the documentation. Every necessary verbal hint reveals something that should be added to the handover package.

A short checklist for a joint review:

• Can the company obtain the code, documentation and access to the operating accounts without the founder's involvement?
• Does the company control the repository and have the ability to add a new supplier?
• Can you identify the version that matches the application running in production?
• Can the incoming team run and deploy the application by following the instructions?
• Can it run the tests and understand any failures?
• Does it have an overview of the database, backups, external services and their administrators?
• Are known defects, limitations and unfinished work documented in writing?
• Does the component inventory match the application actually being handed over?

Widely used technologies make it easier to find a team with relevant experience. They do not guarantee clear documentation or complete access. A successful deployment based on the instructions therefore provides stronger evidence than a list of technologies in a proposal.

Our own product in production is Innea, which uses Next.js, TypeScript and Supabase with PostgreSQL. Its testing tools include Vitest and Playwright. It is a concrete example of our stack, not a client reference or evidence of a handover to another team.

Under our terms and conditions, the client has 10 business days after delivery to test the work and either confirm acceptance or describe in writing any defects that prevent its use. If the client does neither within this period, the work or project stage is deemed accepted. We explicitly point out this consequence with every delivery.

Under the terms, minor defects that do not prevent use do not block acceptance, and we repair them under the warranty. In practice, we therefore recommend setting aside time for the review in advance and describing any problems reproducibly: what you did, what should have happened and what actually happened.

The terms provide a 3-month warranty from acceptance and free repair within a reasonable period for defects reported during that time. The warranty does not cover, for example, defects caused by changes made by the client or a third party, changes to the environment or third-party services, or requirements beyond the agreed scope.

Before the incoming team makes changes, it is therefore useful to record the initial state and any existing defects. This makes it easier to distinguish an original problem from a later change. The contractual rules for handover, acceptance and warranty are here:

1. Do we have to rewrite the application when changing suppliers?

   Changing suppliers is not, by itself, a reason to rewrite the application. The new team should first assess the state of the code, documentation, tests and production systems. Only specific findings can show which parts need to be changed.

2. Does Iterus charge separately for handover?

   According to our published process, handover is included in the price of every pricing band and is not an extra charge. We recommend specifying the exact scope of the materials and the verification test in the project brief.

3. Can we continue modifying the application ourselves?

   Under our terms and conditions, once the full price of the work or project stage is paid, the licence includes the right to make modifications. Third-party components remain subject to their original licences. After later changes, you also need to distinguish original defects from defects caused by those changes.

4. Who will take over the project if the founder is unavailable?

   You can choose another team with experience in the technologies used. For a specific project, it is worth verifying in advance that you can obtain the access and materials without the founder's personal involvement. We do not promise a backup operator or a guaranteed takeover time.