A software project handover should let a new developer take responsibility for the application without depending on the previous developer’s personal accounts, laptop or memory. The useful deliverable is a working chain of evidence: which code produced the live release, who controls each service, how a change reaches users, and what happens when something fails.
Use this checklist when changing agencies, bringing development in-house or taking over an unfinished AI-built app. It includes an account manifest and a fictional booking-app acceptance exercise. The exercise is a planning tool, not a report of a MUBBITS customer project. Your signed agreement should establish commercial ownership, access, support and the work included in the transition.
Key takeaways
- Identify the live release and its source before accepting a folder of code.
- Give the receiving team access through accounts the business can administer.
- Ask the incoming developer to build and deploy a reviewable change in an isolated environment.
- Transfer operating knowledge, open issues and recovery responsibilities alongside the repository.
- Record unresolved items and the support boundary before the outgoing team leaves.
Start with the product people are using
Write down the public web address, mobile store listings, backend environments and the customer journey that must keep working. A business may have a public website, a customer app, an admin workspace and a scheduled worker maintained in different repositories. Treat those as separate items until the team can explain their relationship.
For each deployed component, record the release identifier and the source commit or build provenance available. Ask the outgoing developer to explain any gap between the repository and the running product. An uncommitted production fix, a manually uploaded asset or a function deployed from another directory belongs in that gap record.
Choose one representative workflow to follow through the handover. For a booking product, that might be a customer creating an appointment and a coordinator viewing the correct appointment. This gives both teams something concrete to demonstrate while they work through the infrastructure.
Create an account and responsibility manifest
The owner needs a map of the services that keep the product running. Record who can administer each account, who pays for it, how an authorized person recovers access and which incoming person will maintain it. Keep passwords, recovery codes, private keys and customer data out of the manifest itself; reference the agreed secure access channel.
Use individual invitations and suitable roles where the provider supports them. Confirm the business can manage memberships and billing after the transition. A shared login that works today can still leave the owner unable to recover the account later.
| Asset or service | Owner and operator to identify | Evidence the incoming team should provide |
|---|---|---|
| Source repositories | Business-controlled organization and responsible maintainer | Repository access, required branches, release references and dependency lockfiles |
| Hosting and deployment | Account administrator, billing owner and release operator | A deployment history, environment map and documented release path |
| Database and file storage | Data owner, authorized administrator and recovery operator | Where records and actual files live, plus a usable recovery procedure |
| Domain and DNS | Registrant/account custodian and DNS administrator | Access and renewal responsibility for the domain and relevant records |
| Identity and email | Identity-provider administrator and delivery-service operator | Authorized configuration access, callback settings and failure contacts |
| Payments and connected tools | Business account owner and integration maintainer | Test-mode access, event destinations and a way to investigate mismatches |
| Mobile distribution | Store account owner, Expo/EAS owner where used and release maintainer | App identifiers, build profiles, signing responsibilities and submission access |
| Monitoring and support | Incident responder and escalation contact | Alert routing, logs access, support hours and unresolved incident notes |
Ask the receiving developer to reproduce a build
A useful README explains the runtime and package-manager versions, installation, environment-variable names, local startup and the checks needed before a release. It should also explain where configuration values are supplied. An example environment file should contain names and safe placeholders rather than working production credentials.
Have the incoming developer follow that documentation from a clean checkout. Record what had to be clarified or repaired: an undocumented generated file, a missing migration, an unavailable package or a tool that only exists on the previous developer’s machine. Add those findings to the handover record instead of treating the first successful start as the end of the exercise.
Then run a small agreed verification against representative test data. The result should identify the commit, environment and checks performed. A screen recording can help an owner follow the exercise, but the reproducible instructions and findings remain the durable handover.
Transfer access without breaking the running system
Plan the order of invitations, transfers, credential changes and outgoing-access removal with the people who operate the product. Confirm replacement access and a rollback route before changing credentials that a live deployment or scheduled job may use. Rotate or revoke credentials through the provider’s supported controls, with a named person checking the affected integrations afterward.
Provider transfers have their own behavior. GitHub documents that repository webhooks, services, secrets and deploy keys remain associated after a repository transfer. A change of repository owner therefore needs a review of those connections; it should not be treated as automatic credential cleanup.
Keep a dated access-change log with the service, authorized operator, change made and verification result. Record exceptions explicitly, including an integration whose credentials cannot yet be replaced or an outgoing administrator retained for a defined support period.
Give your next developer a clear starting point.
Share the current app, ownership gaps and the work that must continue. We can scope a takeover around access, reproducible builds and agreed acceptance.
Check mobile and data dependencies separately
For an Expo application, identify the owning account, EAS project, app identifiers and build/submission responsibilities. Expo provides account roles and a project-transfer process; use its current account guidance for the actual transfer conditions. Keep store ownership, signing and push-notification setup visible as separate parts of the application’s release path.
For a data-backed product, list database backups and file storage separately. Supabase, for example, states that database backups exclude the actual objects stored through its Storage API. The receiving team should know what each backup covers and how the full workflow is recovered.
If the handover also involves moving records to a different platform, use a separate migration plan. That work has its own extraction, transformation and cutover acceptance conditions.
Expo: account roles and project ownership
Run an acceptance exercise on a fictional booking app
Imagine a small booking application with a customer site, coordinator dashboard, payment integration and reminder worker. The new team inherits the source and receives appropriate test access. Its first handover exercise should prove that it can operate the intended workflow and explain the system around it.
The table is an original example to adapt. Use an isolated environment, test accounts and sandbox integrations. Agree the checks before the demonstration so that both parties know what evidence will count. A failed check becomes a named finding with an owner and next action.
| Exercise | Evidence to keep | If it fails |
|---|---|---|
| Identify the reviewed release | Source commit, build identifier and environment named together | Explain the source/deployment gap before further changes |
| Create a test booking | Customer and coordinator can find the same intended record | Capture the broken step and affected role |
| Verify account boundaries | An unrelated test account cannot read the private booking | Treat access-control findings as a release blocker for that journey |
| Deploy a contained staging change | Incoming operator follows the documented pipeline and can reverse the change | Document missing access, configuration or rollback steps |
| Trace a failed reminder | The operator finds a sanitized event, its job status and the escalation owner | Add the missing observability or support responsibility to the scope |
| Explain recovery coverage | A recovery runbook identifies records, files and configuration dependencies | Record untested recovery steps and arrange a separate restore drill |
Make open work and support boundaries readable
Ask for the known-issues list, recent incidents, deferred security findings and external deadlines that affect the next release. Include upcoming domain renewals, store submissions, expiring credentials or provider migrations where relevant. Each item needs enough context for someone who did not build the system: reproduction, affected area, current workaround and a responsible person.
Agree what the outgoing team will answer after handover and for how long. Separate clarification of delivered work from new development or a newly discovered inherited defect. The receiving team also needs to know who owns a production incident during the transition itself.
A concise decision log is often more useful than a large document dump. Keep the reason for an unusual design choice, a dependency that could not be changed and any rejected alternatives that still matter. Archive superseded instructions so the new operator can find the current process.
Sign off with evidence and a remaining-work list
Finish with an agreed inventory, the acceptance results, access-change record, current operating instructions and a list of unresolved items. Identify who accepted each part and which responsibilities start on the handover date. Keep sensitive supporting files in the agreed private location.
If the app is unfinished, the handover should make that state understandable. Preserve useful code, describe the blockers and estimate a contained next phase against observable acceptance conditions. MUBBITS can review an inherited or AI-built application and help define that scope. Start with a preview, the intended customer journey and the problems that keep recurring; arrange source access through an agreed channel after the initial conversation.
Frequently asked questions
What should a software project handover include?
Include the source and release references, business-controlled account access, build/deployment instructions, data and recovery coverage, integration details, monitoring, open issues and an acceptance record. Adjust the inventory to the product rather than treating one template as universal.
Can we change developers before the app is finished?
Yes, when the access and source needed for a review are available. Document what works, what remains uncertain and the first customer journey to complete. The incoming developer should assess the inherited code before committing to a completion estimate.
Should the new developer receive production passwords in a document?
Use agreed secure access methods and provider roles where available. The handover document should identify the account, administrator and access procedure without becoming a collection of working credentials or recovery codes.
Does moving a repository finish the handover?
It completes one part. The receiving team still needs to connect the source to the deployed release, understand external accounts and integrations, reproduce a build and demonstrate the operational responsibilities it is accepting.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.