How to Share an App Prototype With Clients Safely

Share an App Prototype With a Client Safely

When you share an app prototype (an early, partly working version of an app) with client reviewers, the upload is the easy part. It is harder to keep the unfinished work private and to answer these questions. Does the demo contain private data? Will the link still work after tomorrow’s revision? Where do comments go? Will a simulated button look like a finished feature?

In short, a good client app preview link does four things. It sets expectations before the first click. It controls who can open it. It keeps feedback tied to the current version. It gives reviewers one response channel.

This guide is about static prototypes and browser-based demos. These are HTML, CSS, JavaScript, images, and documents that run without a private server. The guide explains safety checks, protected access on Cloudflare Pages, Vercel, or Netlify, stable updates, and feedback.

Define What the Client App Preview Link Can Prove

Before you publish, write a review goal in one sentence. Clients who expect a finished application can judge a prototype by the wrong standard. So state what works, what is simulated, and what is missing.

A static prototype can show:

• Visual design, such as layout, typography, colors, responsive behavior, and content hierarchy
• Browser behavior, such as navigation, menus, filters, local calculations, and scripted transitions
• Prepared scenarios, for example sample records from JSON files or browser storage
• Supporting material, such as a proposal, deck, specification, or short usage note next to the demo

It cannot safely hide an API secret or run server-side code. A simulated AI response does not prove that authentication, billing, database writes, queues, or production AI calls work.

Prototype state	What to tell the client	Suitable review question
Static screens	Data and actions are simulated	Is the workflow understandable?
Interactive front end	Clicks, menus, and filters work with sample data	Can you complete the main task?
Connected test build	Some approved test services are live	Does the connection to that service behave as expected?

Put the scope inside the demo, not only in the email. Forwarded links often lose that explanation.

Run Safe Pre-Publish Checks for Static Prototype Sharing

Costly preview mistakes are often small. Examples are an exposed token, a broken route, or a mobile button below the fold (out of view until you scroll). Test the exported folder in the same way as a client who opens it for the first time.

Item	What to check	Why it matters
Sensitive data	Search files for API keys, tokens, customer records, private URLs, and internal comments	Visitors can inspect or download every file that the browser loads
Navigation	Open every route, then refresh nested pages	Local paths can work while hosted paths fail
Actions	Disable or label destructive, paid, and production-facing controls	A realistic button can create a false expectation
Devices	Test desktop and narrow mobile layouts, keyboard navigation, and a private browser window	Your signed-in development browser hides access problems
Version	Show a date or revision label inside the prototype	Feedback needs a clear reference point

Also test the performance. Google recommends three Core Web Vitals targets (web.dev). The target for Largest Contentful Paint is 2.5 seconds or less. The target for Interaction to Next Paint is 200 milliseconds or less. The target for Cumulative Layout Shift is 0.1 or less. Google measures these values at the 75th percentile of page views. A temporary preview does not have to meet them exactly. But a slow first screen affects how the client sees the design.

WCAG 2.2 asks for keyboard operation and a contrast ratio of at least 4.5:1 for normal text (W3C). A prototype does not have to be perfect, but it must not block reviewers.

Choose Access for a Protected Demo Site

Choose the access level that matches how sensitive the work is. An obscure URL is convenient, but it gives no real protection. Links appear in chats, synced browsers, forwarded email, screenshots, and analytics logs.

Access method	Where you get it	Best for	Main tradeoff
Public link	Any host	Low-risk concepts that you want people to pass on	Anyone with the URL can open it
Shared password	Netlify on Pro plans and above, or Vercel as a paid add-on on Pro	A known client team that reviews confidential work	Someone can forward the password with the link
Emailed one-time code	Cloudflare Access in front of Cloudflare Pages	Named reviewers, with a record of who signed in	One extra step before entry
Host account login	Vercel Authentication, on all Vercel plans	Reviewers who have, or will create, a Vercel account	Clients without an account need a shareable link instead

Cloudflare Pages with Cloudflare Access

With this method, clients get in with only their email address. Upload the prototype folder with Direct Upload (Workers & Pages > Create application > Get started > Drag and drop your files). Under Custom domains, add a custom domain such as demo.example.com. Then create a self-hosted Access application for that hostname. Give the application an Allow policy. The policy includes the addresses of the reviewers (Emails) or the domain of the client (Emails ending in). Turn on the one-time PIN login method. Each reviewer enters an email address and receives a code that expires after 10 minutes.

Protection on the custom domain does not protect the pages.dev address of the project. Cloudflare’s Pages known issues page lists the steps to put that address behind Access as well. The Cloudflare Pages access guide shows the whole setup.

Vercel Deployment Protection

If the prototype is a Next.js or similar app already on Vercel, use Deployment Protection in the project settings. Standard Protection is available on all plans. It protects every deployment except production domains. All Deployments also protects production. With Vercel Authentication, visitors must sign in with a Vercel account that has access. They can also request access, and you approve the request.

For a client without a Vercel account, create a shareable link. Open Deployments and select the preview deployment. Select Share, and choose Anyone with the link. To revoke the link, set it back to Only people with access. On the Hobby plan, you can create only one shareable link per account.

Netlify password protection

Netlify’s password protection puts a shared password in front of the site on Pro plans and above. On credit-based Pro plans, the setting is under Project configuration > General > Visitor access > Project visibility. There, you can protect production and previews, or only previews.

Protection is not a security review

Use a password that is different from your account credentials. For sensitive material, send the password separately from the link. A protected demo still needs sensible content. Protection reduces casual exposure, but it does not replace contracts, NDAs, source-control permissions, or security reviews. Before you upload, remove production data. When the engagement ends, close access.

A Content Security Policy is a header that limits the sources that a page can load. OWASP describes it as a second layer of protection (OWASP CSP guidance). It is useful even on a fully static site, because it can limit what third-party scripts load. On Cloudflare Pages, you can add it with a _headers file. The same file can add X-Robots-Tag: noindex to your pages.dev addresses. This header keeps them out of search results. Netlify adds a noindex header to its Deploy Previews, and by default search engines do not index Vercel previews.

Keep One Client App Preview Link Through Updates

A new URL for every revision causes confusion. One person reviews version two while another comments on version four. A stable client app preview link keeps one address while the files behind it change.

Here is a practical sharing flow:

1. Export the prototype to a clean folder, without source maps, unused assets, local notes, secrets, or unneeded test data.
2. Deploy it to the address that you will keep. This can be a custom review domain on Cloudflare Pages, a Vercel branch URL, or a Netlify site.
3. Set access. Then open the link from a private browser window, and test it from the first screen.
4. Send the link with the review goal, version label, access instructions, and a response date.
5. After each revision, deploy to the same place. On Cloudflare Pages, select Create a new deployment in the project. On Vercel, a Git branch URL always points at the latest deployment from that branch. The client keeps the same link.

If your build tool supports hashed asset filenames (names that change when the file changes), use them. Then browsers fetch the changed JavaScript and CSS and do not reuse old copies.

Keep a dated local copy of every client-facing release. The live link shows the latest version, and your archive keeps what the client saw earlier.

Collect Client Prototype Feedback and Time the Follow-Up

Email threads are a poor way to track prototype bugs. A comment like the button feels wrong is useless without the screen, device, and version. Put the feedback path next to the work. Choose one channel that suits your reviewers.

For teams, use on-page comments. Vercel Comments work on preview deployments through the Vercel Toolbar. Everyone who comments needs a Vercel account. Netlify’s Deploy Previews include the Netlify Drawer for comments, screenshots, and video.

For clients without accounts, use a form. Add a feedback form with Netlify Forms. To do this, turn on form detection, and then add data-netlify="true" to the form tag. You can also embed a Google Form on any host.

Ask reviewers to include:

• The name of the page, screen, or component
• What they clicked or tried to do
• What happened and what they expected
• The device and browser, and whether the issue repeats
• The priority: blocking decision, requested change, or later polish

To time your follow-up, find out who opened the preview. With Cloudflare Access, the Access authentication logs in Zero Trust list each sign-in with the email address and time. On Vercel, an access request sends an email and a notification to the branch authors. Use this data for timing, not to guess what the client thinks. If the client opens the pricing screen, this does not mean that the client approves the price.

When a decision-maker opens the demo, follow up while the review is fresh. If nobody opens it, first make sure that the link arrived and that the access instructions are correct. If several people visit but do not respond, ask one focused question instead of a request for general thoughts. Tell reviewers what you record, and collect only the identity data that you need.

Four Ways to Share an App Prototype With a Client

These examples show common review patterns:

• For an agency landing-page concept, an agency exports two responsive HTML campaign variants to Cloudflare Pages. It puts them behind Access for four named reviewers. Each variant links to a short feedback form with one question: which message goes into production?
• For an AI support assistant, a builder publishes a browser-only interface with 12 fictional support tickets and prepared AI responses. The demo labels generation, customer records, and account permissions as simulated. No model key goes to the browser. The client reviews tone and workflow, and the demo does not imply a finished production system.
• For a consulting proposal, a consultant deploys an interactive cost calculator to Netlify behind a password and links to it from the proposal document. The proposal states which numbers are illustrative, and a Netlify form collects questions.
• For a product redesign, a small team shares a Next.js dashboard from a Vercel branch. The branch has Vercel Authentication and a shareable link for the client. The client reports a mobile filter that is hard to find. The team pushes a fix and changes the visible label from revision 1.2 to 1.3. The branch URL already shows the new build.

Each example gives the client a narrow question, safe sample data, and one response channel. This is more important than a finished look for an early prototype.

Avoid Common Protected Demo Site Failures

A polished screen can make people careless. A clearly labeled rough prototype is better than a beautiful demo that leaks credentials or implies features that do not exist.

Failure	Why it happens	Better choice
Treating an unlisted URL as private	The address looks random	Use a password, an emailed code, or a host login for sensitive work
Protecting only the custom domain	People forget the default host address	Protect the pages.dev or other generated address too
Embedding an API key	The front end needs a live service	Use fixtures, mock responses, or an approved test setup with server-side credentials
Uploading real customer data	Someone copied sample data from production	Create fictional records and remove personal information
Sending a new URL after each edit	Each export feels like a separate release	Deploy to the same project or branch behind one stable link
Collecting feedback in many channels	Reviewers reply wherever it is convenient	Name one primary feedback route
Reading visits as approval	People mistake visits for decisions	Ask directly for the decision that you need
Hiding prototype limits	The demo looks more complete than it is	Put limitations and simulated actions on the first screen

Test the access gate after every meaningful change. A working prototype with broken login instructions still fails. Before a major presentation, open the exact link on a different device and network.

Final Thoughts

Treat the preview as a small delivery system, not a loose folder on the internet.

State what it proves. Remove secrets and real customer data. Test the exported build outside your normal browser. Choose public access, a password, an emailed code, or a host login. Base the choice on how sensitive the work is.

The best setup gives both sides one stable link, one current version, and one feedback channel. Sign-in records can help you time a follow-up, but decisions still need a direct conversation with the client.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.