A client asks for \"the code\" or \"the latest build folder\" and they want it today. You could add them to the git host, but procurement has not finished, their IT blocks GitHub, or they only need a snapshot for a contractor to review. So you make a zip. That zip is either a clean handoff or a leak waiting to be unzipped.
\nSharing a project archive is a delivery problem, not just a compression problem. Clients open whatever you send. They will not notice that you included `.env`, a production dump, or 400 MB of `node_modules`. This guide is a practical way to build a zip you are willing to let leave the building, plus a checklist for the message that goes with it.
\n\"Send the project\" can mean four different artifacts:
\nAsk one clarifying question before you zip: should they run it, read it, or deploy it? A reader does not need `node_modules`. A deployer needs environment variable names, not your production values. A reviewer may only need one service directory from a monorepo.
\nIf they can accept a git invite, prefer that. History, diffs, and access revocation are better in a real host than in a zip sitting in someone's Downloads folder for a year.
\nBuild the archive from a clean export, not from a right-click on your working tree. A working tree contains machine-local junk and secrets you stopped seeing months ago.
\nAlways exclude:
\nUsually exclude unless they asked:
\nA good pattern is `git archive` from a tagged commit, then add a `HANDOFF.md` you write for humans. `git archive` will not pack ignored build artifacts if your `.gitignore` is honest. It also will not save you if you committed a secret last year. Search the tree for `API_KEY`, `BEGIN PRIVATE KEY`, and `AKIA` before you ship.
\nClients (and whoever they forward the zip to) can find:
\nReplace real values with placeholders: `POSTGRES_PASSWORD=change-me`. List every required variable in `HANDOFF.md` with a one-line purpose. If they need working credentials, send those through a password manager or a one-time secret link, never inside the zip.
\nSmall process, fewer support emails:
\nOn Unix-like systems, something in the spirit of `zip -r project.zip client-project-2026-08-03 -x \".env\" -x \"/node_modules/*\"` is a start, but a dedicated export folder is safer than a long exclude list you will forget to update.
\nClients rarely need the whole cargo cult of packages. If they hired you for a marketing site, do not send the internal billing service. Either:
\nDocument which workspace commands they must run. A zip of `/packages/web` without the root `package.json` is a support ticket, not a handoff.
\nProject zips are often too large for email. Chat apps may accept the file and then fail on the client's guest Wi-Fi.
\nOptions that usually work:
\nTell the client how long the link or room lasts in the same message as the code. If they wait until next week, a two-hour room will be empty. That is not a failure of the zip. That is a mismatch of lifetime and expectation.
\nSend this as the cover note, not as a thought in your head:
\nIf legal ownership is unclear, do not \"just zip it.\" A contract line about deliverables is cheaper than an argument about a repo that also contains another customer's theme.
\nA panic zip is your `~/code/app` folder, including `.env.production`, `node_modules`, and a database named `real-users.sql`. A good zip is a dated folder, an example env, a handoff note, and a size that makes sense for source.
\nReview the archive yourself: unzip it into `/tmp`, install, run. If you cannot, the client cannot. Fix the handoff on your machine, not in their inbox.
\n| Method | Client account needed | Easy to revoke | Good for huge repos | Typical use |
|---|---|---|---|---|
| Git host invite | Usually yes | Yes | Yes (they clone) | Preferred when IT allows it |
| Signed cloud URL | No | Expire the URL | Yes | Async handoff |
| Temporary chat + file room | No | Room expires | Practical for snapshots | Same-day send |
| Email attachment | No | No | Poor | Tiny docs only |
| Encrypted USB | No | Physical | Yes | Air-gapped / legal |
A project zip is a snapshot of trust. Exclude secrets, caches, and customer data. Export from a known commit. Write the runbook you wish every vendor had sent you. Deliver through a channel whose lifetime matches the client's calendar, and keep the canonical copy in git. If they only needed a preview, send a built folder or a staging URL instead of your entire working tree. Fast handoff is not the same as a reckless zip—and clients remember which one you chose.
","content_text":"A client asks for \"the code\" or \"the latest build folder\" and they want it today. You could add them to the git host, but procurement has not finished, their IT blocks GitHub, or they only need a snapshot for a contractor to review. So you make a zip. That zip is either a clean handoff or a leak waiting to be unzipped.\n\nSharing a project archive is a delivery problem, not just a compression problem. Clients open whatever you send. They will not notice that you included `.env`, a production dump, or 400 MB of `node_modules`. This guide is a practical way to build a zip you are willing to let leave the building, plus a checklist for the message that goes with it.\n\nDecide what the client actually needs\n\n\"Send the project\" can mean four different artifacts:\n\n- Source snapshot for another developer to run locally.\n- Built static export (for example `dist/` or `out/`) they can host or preview.\n- Design + code sample of one feature, not the whole monorepo.\n- Handover package with docs, credentials process (not the secrets themselves), and run instructions.\n\nAsk one clarifying question before you zip: should they run it, read it, or deploy it? A reader does not need `node_modules`. A deployer needs environment variable names, not your production values. A reviewer may only need one service directory from a monorepo.\n\nIf they can accept a git invite, prefer that. History, diffs, and access revocation are better in a real host than in a zip sitting in someone's Downloads folder for a year.\n\nZip hygiene: what to exclude every time\n\nBuild the archive from a clean export, not from a right-click on your working tree. A working tree contains machine-local junk and secrets you stopped seeing months ago.\n\nAlways exclude:\n\n- `.env`, `.env.`, `.env.local`, `.env.production`\n- `credentials.json`, `service-account.json`, cloud key files\n- `.pem`, `.p12`, `.jks`, `id_rsa`, `.keystore`\n- `.git/config` remotes that embed tokens (prefer a git bundle or a host invite if they need history)\n- `node_modules/`, `.pnpm-store/`, `.yarn/cache/`, vendor caches\n- `.next/`, `dist/` unless the client asked for a built preview\n- `__pycache__/`, `.venv/`, `venv/`, `target/` for compiled languages unless they asked for binaries\n- IDE folders they do not use (`.idea/` is optional; `.vscode/` may contain local paths)\n- Database dumps, `.sqlite` with real user data, `uploads/` with customer files\n- `.DS_Store`, `Thumbs.db`, editor swap files\n\nUsually exclude unless they asked:\n\n- Large media that already lives in object storage\n- E2E recordings and Playwright traces\n- Internal RFCs that name other clients\n\nA good pattern is `git archive` from a tagged commit, then add a `HANDOFF.md` you write for humans. `git archive` will not pack ignored build artifacts if your `.gitignore` is honest. It also will not save you if you committed a secret last year. Search the tree for `API_KEY`, `BEGIN PRIVATE KEY`, and `AKIA` before you ship.\n\nSecrets are not only .env files\n\nClients (and whoever they forward the zip to) can find:\n\n- Hard-coded tokens in test fixtures\n- Stripe or Twilio keys in old config samples\n- Production URLs with embedded basic-auth\n- Customer names in seed data\n- Internal Slack webhook URLs in deploy scripts\n\nReplace real values with placeholders: `POSTGRES_PASSWORD=change-me`. List every required variable in `HANDOFF.md` with a one-line purpose. If they need working credentials, send those through a password manager or a one-time secret link, never inside the zip.\n\nHow to build a zip that opens cleanly\n\nSmall process, fewer support emails:\n\n1. Commit or stash so you know what you are exporting.\n2. Export from git or copy into a fresh folder named `client-project-YYYY-MM-DD/`.\n3. Add `HANDOFF.md` (stack, Node/Java version, how to install, how to run, what is not included).\n4. Add `.nvmrc`, `.python-version`, or a `runtime.txt` equivalent if you have one.\n5. Include a sample env file only: `.env.example`.\n6. Zip the folder so the archive contains one top-level directory, not 400 loose files.\n7. Note the uncompressed and compressed size. If it is huge, you left `node_modules` or a video in.\n8. Compute a checksum if the project is sensitive or large.\n\nOn Unix-like systems, something in the spirit of `zip -r project.zip client-project-2026-08-03 -x \".env\" -x \"/node_modules/\"` is a start, but a dedicated export folder is safer than a long exclude list you will forget to update.\n\nMonorepos and \"just that app\"\n\nClients rarely need the whole cargo cult of packages. If they hired you for a marketing site, do not send the internal billing service. Either:\n\n- Export the one package plus the lockfile and workspace snippets it needs, or\n- Send a minimal reproduction with the public API mocked.\n\nDocument which workspace commands they must run. A zip of `/packages/web` without the root `package.json` is a support ticket, not a handoff.\n\nHow to deliver the archive\n\nProject zips are often too large for email. Chat apps may accept the file and then fail on the client's guest Wi-Fi.\n\nOptions that usually work:\n\n- Git host guest access with a read-only deploy key or a time-boxed collaborator seat.\n- Signed object-storage URL from the bucket you already use, expiry measured in hours or a few days.\n- A temporary browser room when the client cannot create accounts and you are both available. PeerPizza is one browser-based option: no account, room code, optional PIN, chat plus files, chunked upload without a fixed per-file size cap, and automatic cleanup after about two hours idle. Keep your own copy. Rooms are temporary on purpose.\n- Courier USB only for air-gapped or legally picky environments, with the drive encrypted.\n\nTell the client how long the link or room lasts in the same message as the code. If they wait until next week, a two-hour room will be empty. That is not a failure of the zip. That is a mismatch of lifetime and expectation.\n\nClient handoff checklist\n\nSend this as the cover note, not as a thought in your head:\n\n- What the zip is (source vs built preview) and the date of the snapshot\n- Git tag or commit SHA if it came from version control\n- Runtime versions (Node, Java, Python, OS assumptions)\n- Install and run commands that you actually ran on a clean folder\n- Required third-party accounts (auth provider, maps key) and who pays for them\n- Environment variable names, with secrets delivered separately\n- What you deliberately omitted (`node_modules`, production data, keys)\n- License and whether they may hire another vendor to modify it\n- Who to ping for 48 hours if `npm install` fails\n- When the download location expires\n- Reminder that they should keep their own backup after download\n\nIf legal ownership is unclear, do not \"just zip it.\" A contract line about deliverables is cheaper than an argument about a repo that also contains another customer's theme.\n\nWhat good looks like vs a panic zip\n\nA panic zip is your `~/code/app` folder, including `.env.production`, `node_modules`, and a database named `real-users.sql`. A good zip is a dated folder, an example env, a handoff note, and a size that makes sense for source.\n\nReview the archive yourself: unzip it into `/tmp`, install, run. If you cannot, the client cannot. Fix the handoff on your machine, not in their inbox.\n\nTroubleshooting project zip handoffs\n\nThe client says the zip is empty or \"corrupted\"\n\n- They double-clicked a partial download. Compare file size and checksum.\n- macOS Archive Utility sometimes chokes on very large zips or unusual permissions. Have them try `unzip` in Terminal, or send a `.tar.gz` as a second option.\n- You zipped a shortcut or an unsynced cloud placeholder instead of the real folder. Confirm the bytes on disk.\n\n`npm install` or build fails on their laptop\n\n- You omitted the lockfile or sent the wrong package manager's lockfile.\n- Native addons need build tools they do not have. Mention Xcode CLT, Visual Studio Build Tools, or Docker as the supported path.\n- Your README assumes global CLIs (`poetry`, `fnm`, `java`) that are not installed. Pin versions.\n- You accidentally shipped `node_modules` for the wrong platform. Do not ship it.\n\nThey cannot receive the file\n\n- Email and Slack size limits. Use a signed URL or a temporary room instead of splitting into `part1.zip` / `part2.zip` unless you have no other choice.\n- Their IT blocks file hosts. Ask which domains are allowed before you upload.\n- They are on a phone. A 200 MB source zip is a laptop job. Say so.\n\nYou already sent secrets\n\n- Rotate every credential that was in the archive. Do not debate whether they \"probably will not look.\"\n- Invalidate the download link or abandon the room.\n- Send a replacement zip and a short note that the previous archive is withdrawn.\n- Check git history if that zip was built from a commit that still contains the secret.\n\nDelivery options compared\n\n| Method | Client account needed | Easy to revoke | Good for huge repos | Typical use |\n| --- | --- | --- | --- | --- |\n| Git host invite | Usually yes | Yes | Yes (they clone) | Preferred when IT allows it |\n| Signed cloud URL | No | Expire the URL | Yes | Async handoff |\n| Temporary chat + file room | No | Room expires | Practical for snapshots | Same-day send |\n| Email attachment | No | No | Poor | Tiny docs only |\n| Encrypted USB | No | Physical | Yes | Air-gapped / legal |\n\nFinal thoughts\n\nA project zip is a snapshot of trust. Exclude secrets, caches, and customer data. Export from a known commit. Write the runbook you wish every vendor had sent you. Deliver through a channel whose lifetime matches the client's calendar, and keep the canonical copy in git. If they only needed a preview, send a built folder or a staging URL instead of your entire working tree. Fast handoff is not the same as a reckless zip—and clients remember which one you chose.","word_count":1691,"author":{"name":"Vishvajeet Shukla","url":"https://vishvajeetshukla.in","same_as":["https://vishvajeetshukla.in","https://twitter.com/vishu_07","https://x.com/vishu_07"]},"seo":{"canonical":"https://peerpizza.vercel.app/blog/share-project-zip-with-clients"},"citation_policy":{"attribution_required":true,"link_back_required":true,"canonical_field":"url"}}