What to Review Before You Publish a Code Demo

Publishing a frontend demo turns a private experiment into a document another person may trust, copy, or send onward. A five-minute review prevents the most expensive mistakes.

Remove private material

Search for API keys, access tokens, internal hostnames, email addresses, customer names, and copied production data. Inspect comments and hidden inputs as well as visible text. Replace realistic personal information with obviously fictional fixtures. If a secret was ever published, deleting the page is not enough—revoke and rotate it.

Verify ownership

Confirm that you may redistribute every image, font, icon, audio clip, and code fragment. A source link is not a license. Record the license when reuse depends on one, and avoid implying affiliation with a company merely because the demo resembles its interface.

Test behavior and access

Reload from the published link, not only the editor. Use the keyboard, check visible focus, zoom the page, and try a narrow viewport. Ensure controls have names and errors explain recovery. Disable motion to confirm that information is not available only through animation.

Explain the artifact

A useful title describes the behavior. The description should say what the demo is for, what is simulated, and what feedback is wanted. Remove dead controls and “coming soon” sections that make the artifact appear unfinished.

Consider the audience

Do not publish phishing simulations, credential forms, destructive commands, malware demonstrations, adult content, hate, illegal sales, or instructions that enable unauthorized access. Even legitimate security education needs a controlled venue and context beyond an anonymous visual demo.

After publishing, open the link once more in a signed-out browser. Confirm that it contains no advertising or tracking you did not intend. Keep the share URL so you can update, delete, or report the work later. Public code is most valuable when readers can understand both what it demonstrates and where its boundaries are.

Reduce the artifact to its intended claim

Before publishing, write one sentence describing what a reviewer should learn or decide. Remove panels, sample records, and controls that do not support that claim. This is not merely a file-size exercise: every extra behavior creates another implied promise. A prototype of a checkout error does not need a complete account menu, and a typography comparison does not need a realistic analytics dashboard.

Keep the states needed to challenge the claim. Include long text when demonstrating layout, errors when demonstrating a form, and keyboard behavior when demonstrating interaction. Delete accidental complexity while preserving deliberate pressure. If you cannot explain why an element is present, it is probably noise.

Replace hidden dependencies

Open the shared result in a clean browser profile and on a second network if possible. Look for local file paths, development servers, authenticated APIs, private fonts, expiring storage URLs, and assets allowed only by your current CORS configuration. Replace them with embedded fixtures or explicitly public, stable resources. Do not copy production customer data into the demo just because it makes the screen realistic.

Search source and rendered output for tokens, email addresses, internal hostnames, issue numbers, comments, source maps, and environment values. Inspect network requests as well as text files. A secret fetched at runtime is still exposed. If the example needs an API, use inert sample responses and clearly label destructive actions as simulated.

Review the security model

Treat a share URL as public even when it is difficult to guess. Untrusted HTML should render in a sandbox that cannot access the host page’s cookies or storage. External links and form actions need protocol validation. Avoid top-level navigation, popups, clipboard writes, downloads, and permission requests unless they are the behavior under review. When such capabilities are necessary, enable the smallest sandbox permission and document the reason.

Try obvious hostile inputs: closing tags, event handlers, script URLs, oversized data, and text that resembles system instructions. Confirm that errors fail closed and remain understandable. A visual preview can still cause harm through phishing or misleading navigation even when its script is isolated.

Make review reproducible

Put setup, interaction steps, expected result, and known limitations beside the artifact. Include browser and viewport requirements only when they matter. Freeze random data, dates, and animations or add a reset control so two reviewers see the same starting state. If timing is central, state the expected range and how it was measured.

Ask a second person to follow the instructions without a verbal explanation. Note every question they ask: each one reveals context that lives only in the author’s head. Update the shared page, not a separate chat message, so the explanation travels with future copies.

Plan the artifact’s lifecycle

Decide who can remove the demo, how abuse is reported, and when links should expire. Give owned work a clear delete path and avoid indexing raw user submissions by default. If the example becomes canonical documentation, move it into a reviewed publishing workflow instead of leaving an anonymous prototype to serve indefinitely.

The final review is a release review in miniature: scope, data, dependencies, security, accessibility, performance, and ownership. Passing it does not make a prototype production-ready, but it makes the prototype honest, safe to inspect, and useful to people who were not present when it was created.