Use this source code handoff checklist to export, document, rotate secrets, run migrations, validate builds, and confirm deployment ownership with clients.

A source code handoff is the moment the project stops being “something the agency can run” and becomes “something the client can own.” Without a clear handoff, common problems show up fast: the app builds only on one laptop, production depends on a secret that nobody can find, or a small update turns into days of guesswork.
The goal of any source code handoff checklist is simple: after the transfer, the client can build, run, and deploy the product without needing the agency on call. That does not mean “no support ever.” It means the basics are repeatable and documented, so the next person can pick it up with confidence.
What counts as deliverables should be explicit. At minimum, a complete handoff usually includes:
Scope matters as much as content. Some handoffs cover only one environment (for example, production). Others include dev, staging, and production with separate settings and processes. If you do not name which environments are included, people assume different things, and that’s where outages happen.
A practical way to define success is a verification test: a person who did not build the app can export the code (for example, from a platform like Koder.ai), follow the docs, set environment variables, run migrations, build, and deploy to the agreed environment.
This checklist focuses on technical readiness: environment variables, secrets rotation, database migrations, deployment scripts, and build verification. It does not cover legal terms, contracts, IP clauses, or payment disputes. Those matter too, but they belong in a separate agreement.
A clean handoff starts before any export happens. If you agree on who owns what and when, you avoid last-minute surprises like broken deployments, unpaid hosting, or missing access.
Pick a handoff date and define a freeze window (often 24-72 hours) where only urgent fixes go in. This keeps the exported code and the running system in sync. If a hotfix is needed during the freeze, write down exactly what changed and make sure it is included in the final export.
Decide who will own DNS, cloud hosting, and any paid services after the handoff. This is not just paperwork. If billing stays on the agency card, services can be paused later without warning.
A quick way to make it concrete:
Write this down in plain language so both sides can follow it.
Agree on what environments exist (local, staging, production) and where each one runs. Note whether staging is a separate server, a separate database, or just a feature flag. If you used a platform like Koder.ai, also confirm what is hosted there vs what is expected to run in the client’s infrastructure after export.
Do not wait until the last day to request access. Make sure the right people can reach what they need: the repo, CI, hosting, the database, and the email provider.
Also agree on the final acceptance test and sign-off process. For example: “Client can build from a clean machine, run migrations, deploy to staging, and pass the smoke test. Then both sides sign off in writing.”
A good source code handoff checklist starts with a repo that a new team can open and understand in minutes. Confirm what is included (app code, config templates, scripts) and what is intentionally missing (real secrets, private keys, large generated files). If something is excluded, say where it lives and who owns it.
Keep the structure predictable. Aim for clear top-level folders like frontend/, backend/, mobile/, infra/, scripts/, and docs/. If the project is a monorepo, explain how the pieces relate and how to run each one.
Your README should be usable by someone who did not build the project. It should cover prerequisites and the fastest path to a working dev run, without guesswork.
Include a short, human README section that answers:
Add simple architecture notes in plain language: what talks to what, and why. A small diagram is optional, but a few sentences are usually enough. Example: “React frontend calls the Go API. The API reads and writes PostgreSQL. Background jobs run as a separate worker process.”
Finally, include a versioned changelog or release notes for the handoff build. This can be a CHANGELOG.md or a short “handoff release notes” file that states the exact commit/tag, what was shipped, and known issues.
If the code was exported from a platform like Koder.ai, note the generated project type (web, server, mobile), the expected toolchain (for example React, Go, PostgreSQL, Flutter), and the supported OS/tooling versions the client should use to reproduce the build.
Environment variables are often the reason a “working app” fails right after handoff. A good source code handoff checklist treats them like part of the product, not an afterthought.
Start by writing an inventory that a new team can follow without guessing. Keep it in plain language, and include an example value format (not real secrets). If a variable is optional, say what happens when it is missing and what default is used.
A simple way to present the inventory is:
Call out environment-specific differences clearly. For example, staging might point to a test database and a sandbox payment provider, while production uses live services. Also note values that must match across systems, like callback URLs, allowed origins, or mobile app bundle identifiers.
Document where each value lives today. Many teams split values across places: local .env files for development, CI variables for builds, and hosting settings for runtime. If you used a platform like Koder.ai to export the app, include a .env.example file and a short note on which variables must be filled in before the first build.
Finally, prove there are no secrets hiding in the repo. Don’t just check the current files. Review commit history for accidental keys, old .env files, or copied credentials in sample configs.
Concrete example: a React frontend plus a Go API might need API_BASE_URL for the web app, and DATABASE_URL plus JWT_SIGNING_KEY for the backend. If staging uses a different domain, write both values and say where to change them, so the new team doesn’t ship staging settings to production.
A handoff is not complete until the client controls every credential the app needs. That means rotating secrets, not just sharing them. If an agency (or a former contractor) still has working keys, you have an open door you cannot audit.
Start by making a full inventory. Don’t stop at database passwords. Include third-party API keys, OAuth client secrets, webhook signing secrets, JWT signing keys, SMTP credentials, storage access keys, and any “temporary” tokens sitting in CI.
Here’s a simple source code handoff checklist for rotation day:
After rotation, prove nothing broke. Run quick “real user” tests instead of only checking logs.
Focus on flows that depend on secrets:
Example: if you exported a project from Koder.ai and the app uses a payment provider plus email delivery, rotate both keys, redeploy, then place a small test transaction and send a test email. Only after those succeed should you revoke the agency-owned keys.
Finally, document where secrets live going forward (vault, CI variables, or hosting settings), who can change them, and how to roll back safely if a rotation causes errors.
A handoff can look “done” while the database is the part that breaks first. Treat migrations and data like a product of their own: versioned, repeatable, and tested.
Start by writing down the current database version and where migrations live in the repo. Be specific: the folder path, naming pattern, and the latest migration ID (or timestamp). If you’re using PostgreSQL (common with Go backends), also note any required extensions.
Include a short runbook that answers these questions:
Rollbacks deserve honesty. Some changes are reversible only with a backup restore. Call that out in plain language, and pair it with a backup step (snapshot before deploy, verify restore process).
Before handoff is complete, run migrations on a copy of production data if possible. This catches slow queries, missing indexes, and “works on empty data” issues. A realistic test is exporting code, setting environment variables, restoring an anonymized dump, then applying migrations from scratch. That single exercise validates a big part of any source code handoff checklist.
If the app was built in a platform like Koder.ai and then exported, double-check that migration files and any seed scripts are included in the export and still referenced correctly by the backend startup process.
A handoff is only complete when someone else can rebuild the app from scratch on a clean machine. Your source code handoff checklist should include the exact build commands, required versions, and the expected output (for example: “web bundle in /dist”, “API binary name”, “Flutter APK location”).
Write down the tools and package managers you actually use, not what you think you use. For a typical stack this might be Node.js (and npm or pnpm) for a React web app, the Go toolchain for the server, PostgreSQL client tools for local setup, and the Flutter SDK for mobile.
Make dependency installs predictable. Confirm lockfiles are committed (package-lock.json, pnpm-lock.yaml, go.sum, pubspec.lock) and do a fresh install on a new computer or clean container to prove it works.
Capture what CI does, step by step, so it can be copied to another CI provider if needed:
Separate build-time config from runtime config. Build-time config changes what gets compiled (like an API base URL baked into a web bundle). Runtime config is injected when the app starts (like database URLs, API keys, and feature flags). Mixing these is a common reason “it works on CI” but fails after deployment.
Provide a simple local verification recipe. Even a short set of commands is enough:
# Web
pnpm install
pnpm test
pnpm build
# API
go test ./...
go build ./cmd/server
# Mobile
flutter pub get
flutter test
flutter build apk
If you’re exporting from a platform like Koder.ai, include any generated CI files or build presets that were used during deployment so the client can reproduce the same build outside the platform.
A good source code handoff checklist does not stop at “here’s the repo.” It also explains how the app gets from source code to a running service, and who pushes the button.
Start by writing down how deployments happen today: fully manual (someone runs commands on a server), CI-driven (a pipeline builds and deploys), or via a hosted platform. Include where configs live, and which environments exist (dev, staging, production).
Make the release steps repeatable. If the process depends on a person remembering 12 commands, turn those into scripts and note the permissions needed.
Give the client enough to deploy on day one:
Agree on downtime expectations. If “zero downtime” is required, say what that means in practice (blue-green, rolling deploy, read-only window for migrations). If downtime is acceptable, define a clear window.
Static assets and caches are common failure points. Note how assets are built and served, when to bust caches, and whether a CDN is involved.
A rollback should be a short, tested recipe tied to a tag or release ID. For example: deploy the previous tag, restore the prior database snapshot if needed, and invalidate caches.
If the app was created on Koder.ai and then exported, mention the last known good snapshot and the exact export version so the client can match code to a working release quickly.
Verification is the moment you learn whether the handoff is real. The goal is simple: someone new can take the exported code, set it up, and get the same app running without guesswork.
Before you start, record what “correct” looks like: the running app’s version, the current commit/tag (if you have it), and one or two key screens or API responses to compare. If the export came from a platform like Koder.ai, note the snapshot or export timestamp so you can prove you tested the latest state.
For smoke tests, keep it short and tied to risk:
If anything fails, capture the exact command, error output, and the env vars used. That detail saves hours when ownership changes hands.
The fastest way to turn a handoff into a fire drill is to assume “the code is enough.” A good source code handoff checklist focuses on the small, boring details that decide whether the client can actually run and change the app without you.
Most problems fall into a few repeat patterns:
Make rotation and access cleanup a scheduled task, not a “when we have time” item. Set a date when agency accounts are removed, service keys are regenerated, and the client confirms they can deploy using only their own credentials.
For env vars, do a simple inventory from three places: the repo, the CI system, and the hosting UI. Then validate it by running a clean build from a fresh machine or container.
For migrations, test with the same database role the production deploy will use. If production requires elevated steps (like enabling an extension), write them down and make ownership clear.
A realistic example: after exporting a project from Koder.ai, the client deploys successfully but background jobs fail because one queue URL was only set in the hosting dashboard. A quick env var audit would have caught it. Pair that with a tagged release and a documented rollback (for example, “redeploy tag v1.8.2 and restore the last snapshot”) and the team avoids downtime.
If you only keep one page from this source code handoff checklist, keep this one. The goal is simple: a clean clone should run on a new machine, with new secrets, and a database that can move forward safely.
Run these checks on a laptop that has never seen the project before (or in a clean container/VM). That is the fastest way to catch missing files, hidden assumptions, and old credentials.
An agency hands off a React frontend, a Go API, and a PostgreSQL database. The client team clones the repo, copies the provided .env.example into real env vars, and creates brand new credentials for the database, email provider, and any third-party APIs. They run go test (or the agreed test command), build the React app, apply migrations to a fresh Postgres instance, and start both services. Finally, they deploy using the documented script and confirm the same commit can be rebuilt later.
Keep the handoff short and owned. A 30 to 60 minute walkthrough usually beats a long document.