You send a client a demo link on Monday. On Friday they approve the flow. Three weeks later someone forwards the same link and asks why it doesn't have the new settings screen.
That isn't necessarily a deployment bug. It may be a handoff bug: nobody said which URL was temporary, when it would stop working, or what would replace it.
On November 6, Vercel announced a CLI option for setting an expiration on a new project. When the deploy creates a project, you can choose a duration and the CLI prints the deadline. Passing the option when deploying to an existing project doesn't change that project's expiration. You can remove a scheduled expiration with vercel project keep before the deadline.
The distinction matters: the expiration applies to the project, not just the link you sent. Vercel documents that deleting a project also removes its deployments, domains, environment variables, and settings. I would reserve this for a deliberately disposable project, not an existing staging or production environment.
This article was prepared with AI assistance. The appointment app and review plan below are hypothetical.
Decide what you are asking the client to review
Suppose the app lets a customer pick a time, see the cancellation policy, and review an appointment before confirming. For this demo, I would ask the client to try just that path with fake customers and test slots. I would leave real calendars, payments, and email delivery disconnected.
Write down three things before deploying: which behavior is up for review, which project is disposable, and which accounts or resources must never be connected. That gives an AI coding tool a boundary it can actually check. My $3 AI App Builder Starter Prompts help turn an app idea into an explicit scope and test plan. You can also start with those three lines in any project notes file.
Put the review deadline before the deletion deadline
I would send the client a note like this:
Please try booking and canceling a test appointment by Thursday at 3 p.m. Pacific. This is a demo with sample data, not the live app. The link is scheduled to expire Monday at noon Pacific. I'll record the accepted changes and confirm whether we're retiring the demo or setting up a separate staging environment before then.
Use the actual timestamp reported by the provider. The gap between feedback and expiration gives you time to save decisions and handle a request to keep the demo. Record who can make that call. Silence isn't approval to move a demo into production.
An expiration also doesn't control who can see the demo while it's online. Vercel's preview-sharing guide distinguishes inviting specific reviewers from using a link that grants access. Choose the narrowest access that fits the review. Test it from the reviewer's perspective; a link that works for you while you're signed in as the owner proves very little about what the client can open.
Keep the work, not the disposable environment
Before sending the link, I would record the revision that produced it, how to recreate the sample data, and where feedback will be collected. If the client sees a wrong cancellation message, the accepted wording belongs in the project notes or issue tracker, not only in a comment attached to a preview you plan to delete.
For the same reason, inventory anything outside the project. A separate test database, storage bucket, or email sandbox needs its own cleanup decision. Don't assume expiring a deployment project also deletes a service owned somewhere else. Never put real customer records into the demo in the first place.
Make the next URL a deliberate decision
When the review ends, choose one of three outcomes:
- Retire the demo. Save accepted feedback and reproducible setup notes. Tell reviewers the link is going away and check that only the disposable project is scheduled to expire.
- Keep it temporarily. Get an explicit decision from the owner, confirm the correct project, remove its expiration before the deadline, and set a new review date. Keeping a demo does not make it production.
- Build a separately owned environment. Set up the client-approved staging or production project, verify access and integrations, then share the new URL. Check that the original demo is not still the link people are relying on.
The useful handoff is a short record: what the client reviewed, what they accepted, where the work survives, and which link is now authoritative. The timer helps clean up the demo. The record is what keeps the decision from disappearing with it.
For a structured path through scope, testing, and launch, see the $9 AI App Builder From Zero field manual. The $3 Starter Prompts are available separately, or get the book and all 40 prompts in the $10 learning bundle.
Bootcamp Bundle (Review Radar) is coming soon. Preview it or request waitlist updates; checkout remains closed:
https://marcusykim.com/review-radar/
You can also find me here:
Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim
