Software Project Handover Checklist: What You Must Receive at Delivery

The day your software is delivered is the day you have most leverage and least information. The developer knows how everything fits together; you know only that it seems to work. A clear handover turns that gap into a document and a set of accounts that you control. This checklist is written for owners who are not technical, and it works with any studio, including us.

Why handover deserves its own plan

Projects usually go wrong at the end for a dull reason: things were set up in the developer's name. The domain is registered to their email, the app is published from their Play Store account, and the code lives on their laptop. Nothing is wrong while the relationship is good. If it ends, you may find that a business you built is not fully yours. The cure is to ask for ownership during the project and to check it before the final payment.

The code and where it lives

You should receive the full source code, not just a working copy of the site. Ask for access to the code repository, which is the online store of the project's files and history, on an account you own. Ask for a note on how to build and run the project, and for the list of third-party libraries it uses. Our glossary explains source code ownership. At VS Tech Builders, full source code, design files, accounts and documentation transfer on final payment, and that is written into our terms.

Accounts and credentials

Every service the product depends on needs to be under your control. Make a list and mark who is the owner of each one:

• Domain name and its DNS settings.
• Hosting, cloud and database accounts.
• Payment gateway account, which must be in your business name, since payouts go there.
• Email, SMS and WhatsApp service accounts.
• Analytics, search console and tag accounts.
• Firebase or other backend project, with you as owner and the developer as a collaborator.
• Google Play developer account and the app signing key, for Android apps.

Passwords should be handed over safely and changed after handover, so the developer no longer holds working credentials unless you grant ongoing access for support.

App store assets

For an Android app, publishing from your own Play developer account matters most, because an app cannot easily be moved later. Ask for the store listing text, screenshots, privacy policy link and the signing key or details of Play App Signing. Our Play Store launch guide covers the account side.

Documentation and training

Ask for three things in writing: a simple user guide for staff, an admin guide for the owner, and a technical note for a future developer that explains the structure, services used and how to deploy. Ask for a recorded or live training session for the people who will use the admin panel, and a place to ask follow-up questions.

Backups and recovery

Find out where backups are kept, how often they run, who can restore them and how long that takes. Ask for one fresh backup of the database and uploaded files to be placed in an account you control. If nobody has ever tested a restore, ask for one test. Our glossary entry on backup and disaster recovery sets out what to look for.

Acceptance and the support period

Agree how you will accept the work: a list of agreed features, tested by your people on real devices, with problems recorded and fixed. Then understand what support follows. Our terms include a 14-day post-launch correction window on every project, plus plan-based support (one month launch support on Standard, three months of priority support on Premium) and optional maintenance retainers. Whatever studio you use, get the correction period, the response time and the cost of later changes in writing.

The checklist in one place

1. Source code in a repository you own, with build notes.
2. Design files and assets such as logos and fonts.
3. Domain, hosting and cloud accounts in your name.
4. Payment gateway and messaging accounts in your business name.
5. Play Store account and signing details for any app.
6. User, admin and technical documentation.
7. A fresh backup and a restore test.
8. Admin training for your staff.
9. Licence details for any paid libraries or services, with renewal dates.
10. Written support terms and response times.
11. Changed passwords, with access removed or limited for the developer.

Make it part of the contract

The easiest time to ask for all this is before work starts, not at the end. Put the list in the agreement and tie the final payment to it. Our six-step process ends with deployment and support for exactly this reason. If you already have a project in progress and want a second opinion on your handover, get in touch.

Frequently asked questions

What should I receive when a software project is delivered?

You should receive the full source code in a repository you own, design files, documentation, admin training, a fresh backup, and ownership or admin access to the domain, hosting, payment gateway and app store accounts. Passwords should be changed after handover. Get the support terms in writing too.

Who should own the domain and hosting account?

You should, in your business name and email. A developer can be added as a collaborator for setup and support. When these are in the developer's name, you depend on their goodwill to renew, move or change them. Check ownership before the final payment.

Does VS Tech Builders hand over the source code?

Yes. Our terms state that full source code, design files, accounts and documentation are transferred on final payment, so there is no lock-in. Every project also carries a 14-day post-launch correction window, with plan-based support and optional maintenance after that.

What if I did not ask for these things during the project?

Ask now, before you make the final payment, because that is when you have most influence. Request the list in writing and agree a date. If the project is already closed, ask the developer politely for access transfers and documentation, and consider a short paid handover if needed.