How to Share an App Prototype With Clients Safely

Share an App Prototype With a Client Safely

Sharing an app prototype with client reviewers without making unfinished work public raises harder questions than uploading it. Does the demo contain private data, survive tomorrow’s revision, provide a feedback channel, or make simulated buttons look finished?

TL;DR: A good client app preview link sets expectations before the first click, controls access, keeps feedback tied to the current version, and gives reviewers one response channel.

This guide covers static prototype sharing and browser-based demos: HTML, CSS, JavaScript, images, documents, and other files that run or render without a private server. It covers safety checks, protected access, stable updates, visitor analytics, and feedback.

Define What the Client App Preview Link Can Prove

Before publishing, write a one-sentence review goal. Clients expecting a finished application may judge a prototype by the wrong standard, so state what works, what is simulated, and what is absent.

A static prototype can demonstrate:

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

It cannot securely hide an API secret or run an arbitrary server-side runtime. 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	Browser interactions work with sample data	Can you complete the main task?
Connected test build	Some approved test services are live	Does the integration behave as expected?

Put the scope in the protected demo, not just the email. Forwarded links often lose that explanation.

Run Safe Pre-Publish Checks for Static Prototype Sharing

Costly preview mistakes are often small: an exposed token, a broken route, or a mobile button hidden below the fold. Test the exported folder as a first-time client.

Item	What to Check	Why It Matters
Sensitive data	Search files for API keys, tokens, customer records, private URLs, and internal comments	Browser-delivered files can be inspected or downloaded
Navigation	Open every deployed route, then refresh nested pages	Local paths may 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, narrow mobile, keyboard navigation, and one 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

Check performance too. Google’s recommended Core Web Vitals targets are 2.5 seconds or less for Largest Contentful Paint, 200 milliseconds or less for Interaction to Next Paint, and 0.1 or less for Cumulative Layout Shift at the 75th percentile. These targets also suit temporary client previews ( web.dev).

The W3C calls for keyboard operation and at least a 4.5:1 contrast ratio for normal text under WCAG 2.2 (W3C). A prototype need not be perfect, but should not block reviewers.

Choose Access for a Protected Demo Site

Match access to the work’s sensitivity. An obscure URL is convenient but offers no meaningful protection. Links can surface in chats, synchronized browsers, forwarded email, screenshots, and analytics logs.

Access Method	Best For	Main Tradeoff
Public link	Low-risk concepts intended for broad circulation	Anyone with the URL can open it
Password gate	A known client team reviewing confidential work	The password may be forwarded with the link
Email gate	Named reviewers, lead capture, and visitor-level activity	Adds one step before entry

Revdoku lets you store a static demo folder and related files in a private bucket and publish a public, password-protected, or email-gated link.

For a password-protected app demo, use a password different from your account credentials and, for sensitive material, send it separately. Use an email gate to distinguish stakeholders’ activity.

A protected demo still needs sensible content. Protection reduces casual exposure but cannot replace contracts, NDAs, source-control permissions, or security reviews. Remove production data before upload. Rotate or revoke access when the engagement ends.

OWASP recommends Content Security Policy, correct content types, nosniff, and careful caching rules. OWASP notes that CSP remains a useful second defense layer on fully static sites (OWASP CSP guidance).

Keep One Client App Preview Link Through Updates

A new URL for every revision creates confusion. One reviews version two while another unknowingly comments on version four. A stable client app preview link keeps one project address as its files change.

A practical sharing flow:

1. Export the prototype to a clean folder, removing source maps, unused assets, local notes, secrets, and unneeded test data.

2. Drag the folder into a Revdoku bucket. Add any needed brief, deck, or specification.

3. Set public, password, or email-gated access, then test the resulting link from the first screen in a private browser window.

4. Send the link with the review goal, version label, access instructions, and response date.

5. Update the bucket’s files after revisions; the address stays stable, so the client needs no new URL.

Use hashed asset filenames or another cache-busting method when supported. Otherwise, old JavaScript or CSS may remain in the reviewer’s cache.

Also keep a dated local copy of every client-facing release. The stable link shows the latest version; your archive preserves earlier client views.

Collect Client Prototype Feedback and Time the Follow-Up

Email threads poorly track client 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.

Revdoku provides built-in feedback and contact forms without a custom backend. Ask reviewers to include:

• Location: page, screen, or component name
• Action: what they clicked or attempted
• Result: what happened and what they expected
• Context: device, browser, and whether the issue repeats
• Priority: blocking decision, requested change, or later polish

Protected-link notifications can notify the owner when someone opens the preview.

Per-visitor analytics show page views, clicks, and downloads; an email gate records leads or identifies invited reviewers. Use this activity for timing, not mind reading. Opening the pricing screen does not imply price approval.

When a decision-maker opens the demo and relevant material, follow up while the review is fresh. If nobody opens it, check the delivery and access instructions first. If several people visit without responding, ask one focused question rather than broadly requesting thoughts.

Tell reviewers what you record and collect only required identity data. Transparent analytics feel professional. Surprise tracking does not.

Four Ways to Share an App Prototype With a Client

The method works across client projects. These examples reflect common review patterns.

• Agency landing-page concept: An agency exports two responsive HTML campaign variants. It uses an email-gated client app preview link for four reviewers. Each has a feedback button and asks one question: which message should move into production?

• AI support assistant: A builder publishes a browser-only interface with 12 fictional support tickets and prepared AI responses. The protected demo labels generation, customer records, and account permissions as simulated. No model key is shipped to the browser. The client reviews tone and workflow without implying production integration.

• Consulting proposal: A consultant places a deck, a PDF scope, and an interactive cost calculator in one bucket. The email gate records which invited stakeholders opened it, while analytics show whether they downloaded the scope. The consultant can follow up without treating a page view as agreement.

• Product redesign: A small team shares a password-protected static dashboard. After the client reports a hard-to-find mobile filter, the team updates the folder and visible label from revision 1.2 to 1.3. The original client app preview link still opens the current build.

Each gives the client a narrow question, safe sample data, and one response channel. That matters more than making an early prototype look finished.

Avoid Common Protected Demo Site Failures

A polished screen can make people careless. I’d rather send a clearly labeled rough prototype than a beautiful demo that leaks credentials or implies nonexistent features.

Failure	Why It Happens	Better Choice
Treating an unlisted URL as private	The address looks random	Use a password or email gate for sensitive work
Embedding an API key	The front end needs a live service	Use fixtures, mock responses, or an approved test architecture
Uploading real customer data	Sample data was copied from production	Create fictional records and remove personal information
Sending a new URL after each edit	Each export feels like a separate release	Update the files behind one stable link
Collecting feedback in many channels	Reviewers reply wherever convenient	Name one primary feedback route
Reading analytics as approval	Visits are mistaken for decisions	Ask directly for the required decision
Hiding prototype limits	The demo looks more complete than it is	Put limitations and simulated actions on the first screen

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

Automation can streamline repetitive releases. Revdoku’s optional API, CLI, and AI-agent workflows can publish to the same bucket model. For occasional client work, dragging the folder into the dashboard is often simplest.

Final Thoughts

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

State what it proves. Remove secrets and real customer data. Test the exported build outside your normal browser. Choose public, password, or email-gated access based on sensitivity.

The best setup gives both sides one stable link, one current version, and one feedback channel. Open notifications and per-visitor activity can help time follow-up, but final decisions require direct conversation.

Start manually: place the static demo and supporting files in a Revdoku bucket, protect and test the link, then send it. Add API, CLI, or AI-agent automation only when repeated publishing justifies it.

Ask ChatGPT to check prototype access

Before sharing, ChatGPT can ask Revdoku what access mode is active for the bucket. Use this to confirm whether the link is public, password protected, or email gated.

Start publishing for free

Connect this AI to Revdoku so it can store files, create, update, and publish websites for me. Read and follow https://revdoku.com/prompt.md. For ChatGPT, Claude, or another cloud AI, connect https://app.revdoku.com/mcp and complete Revdoku OAuth. For a local agent, use Revdoku's browser device sign-in and complete the connection in Revdoku. Never ask me for a password or API key in chat. When Revdoku tools are connected, verify the connection, tell me you’re ready, and ask what I want to publish.

Copy Prompt

or

Create Free Account