App & Website Project Handover Checklist: What You Must Receive Before a Project Is Declared Complete

As a developer who works on apps and websites for businesses every day, I often see the same pattern: clients are extremely meticulous during the development phase, but they let their guard down at the most decisive moment — the handover. Yet this is exactly the point where you receive (or fail to receive) full control over your own business's digital assets. A project that looks "done" can turn into a boomerang if you don't receive the things that are rightfully yours. I wrote this article as a practical checklist you can use right away before signing the project handover certificate.

Why businesses often "lose" at the handover stage

The problem isn't that vendors are always malicious — it's usually down to two things: unclear contracts and clients who don't know what to ask for. Many business owners feel satisfied because the app is running and looks great, then immediately sign the handover certificate. A few months later, when they need an update or want to switch vendors, the problems surface: the source code isn't in their hands, server access is still with the vendor, and the domain turns out to be registered under the vendor's name.

At that point, your bargaining position is completely weak. The vendor can charge high fees for even the smallest change, and you have no other option because you're holding nothing. This is what I mean by "losing at the handover" — not losing a price negotiation, but losing control over assets you paid for yourself.

The complete list the vendor must hand over

Before the project is declared complete, make sure you receive all of the following:

• Complete source code, including backend, frontend, and mobile app code, along with version history (for example, access to the Git repository). Not just build outputs or installers.
• Server and hosting access: VPS/cloud credentials, hosting panel, and database access.
• App admin accounts: super admin accounts, not just regular user accounts.
• Access to third-party services used by the app: payment gateway, WhatsApp API, notification services, and so on.
• Documents: the app development service contract, the handover certificate, and payment receipts.

One important note from my experience: make sure you actually test those accesses, not just receive a written list. Try logging in yourself, try redeploying from the source code if possible. Access that exists on paper but can't be used is the same as having no access at all.

Technical documentation and guides for non-IT staff

Source code without documentation is a prison with a nice label. A serious vendor will hand over two types of documentation:

1. Technical documentation: code structure, how to set up the development environment, how to deploy, API lists, and database schemas. This matters if one day you switch developers or vendors.
2. User guides: simple documents for your staff who aren't IT people — how to manage products, process orders, or export reports.

Don't be shy about asking for a user guide. It's not an excessive request; an app that's great but can't be operated by your own staff only adds to your operational burden.

Bug warranty and account ownership transfer

The two things most often misunderstood are the bug warranty and account ownership.

Bug warranty: what's reasonable is a repair warranty for bugs that appear after the handover, with a specific period clearly stated in the contract. What matters isn't just the duration but the definition: the warranty covers bugs (features not working according to the agreed specifications), not new feature changes or changes requested because business needs have changed. If you request additional features after the handover, that's new work, not a warranty claim.

Account ownership transfer: this is often overlooked and its impact is the most fatal. The domain, hosting, payment gateway account, WhatsApp API, and developer accounts (Google Play/App Store) should be registered under your name or your business entity, not the vendor's name. The vendor may hold technical access during the contract period, but ownership must be yours. If the domain is under the vendor's name and the relationship turns sour, you could lose your own business's website.

The most important lesson from my experience: a good handover isn't about the vendor delivering "the work," but about you receiving full control — over the code, the access, the account ownership, and the ability to continue the project without that vendor. A good vendor will actually facilitate this, not obstruct it.

Red flags and a checklist before signing the handover certificate

Watch out for these signs during the handover process:

• The vendor refuses to hand over the source code citing "company secrets" or "later, once it's fully paid" without a written agreement.
• The domain or critical services are registered under the vendor's name with no commitment to transfer them.
• There's no documentation at all, with the excuse "I'll just explain later if there's a problem."
• The handover certificate is pushed to be signed quickly before you've had time to thoroughly test the app.
• The bug warranty isn't mentioned at all in the contract.

Before signing, run through this quick checklist: (1) I have logged in and tested all admin accounts, (2) I have received and stored the source code in my own place, (3) all important accounts have been or will be transferred to my business's name, (4) the bug warranty and its duration are written in the contract, (5) I have received the technical documentation and user guide, (6) I have read the handover certificate before signing.

You can actually tell whether a handover process will be healthy from the very start of the engagement. If you're still at the stage of choosing a vendor, I've written an honest guide on choosing between a solo developer or a software agency for your business — including how a good vendor typically explains the handover process from the beginning. You can also get a picture of how I work from start to handover on our work process page.

If you're preparing an app or website project and want to make sure the contract and handover are right from the start, don't hesitate to reach out to us via the contact page. Better to spend an hour discussing now than to spend months regretting it later.