Build a Shareable HTML Prototype Without a Build Step

A prototype is most useful when it answers one question. Does the empty state explain the next action? Does a pricing card feel trustworthy? Does the mobile navigation remain understandable? A full repository often hides that question behind installation and build instructions. A single HTML document removes that friction.

Start with the decision

Write down the decision you want from the reviewer before writing markup. “Review my design” is vague. “Can a first-time visitor tell which plan includes exports?” gives the prototype a boundary. Include only the states needed to answer it.

Use semantic HTML first. A button should be a button; navigation should be a nav; a dialog needs a name and a predictable focus order. Styling a generic div is fast initially but makes keyboard testing and review less reliable.

<main>
  <h1>Choose an export plan</h1>
  <section aria-labelledby="starter-title">
    <h2 id="starter-title">Starter</h2>
    <p>PNG export for personal projects.</p>
    <button>Choose Starter</button>
  </section>
</main>

Keep dependencies intentional

For a reviewable prototype, inline the CSS and small JavaScript behavior. If the idea depends on a large framework, the reviewer may end up evaluating loading behavior instead of the interaction. External fonts, images, and scripts also make the result fragile when opened later.

Use CSS custom properties for the few decisions you expect to tune. A small token set for color, spacing, radius, and type makes feedback actionable: changing --space-section is clearer than hunting through twelve unrelated margin declarations.

Share context with the artifact

Give the work a descriptive title and explain what is real, what is simulated, and what feedback you want. Never place API keys, private endpoints, customer data, or copied production source in a public demo. Replace real data with representative fixtures.

Finally, test at narrow and wide widths, with the keyboard, and with reduced motion enabled. The point of a shareable prototype is not merely that it renders. It should let another person reach the intended state and make the decision you designed it to support.

Create a focused prototype.

Create a deterministic starting state

A reviewer should see the same state the author intended. Replace live APIs with small fixtures, freeze dates and random values, and provide a visible reset action. If several states matter, expose them as labeled controls or separate links instead of requiring hidden setup. Keep sample data realistic enough to pressure the layout but invented enough to be safe to publish.

State the expected browser behavior and primary task beside the demo. “Review the empty-state hierarchy” is more useful than “What do you think?” Include the decision deadline or maturity level when relevant: a disposable interaction sketch should not be judged as a production architecture, while a handoff candidate needs stricter evidence.

Package code for inspection

For a small prototype, a single document can be a good distribution format because it removes build and dependency failures. Separate structure, styles, and behavior clearly inside it. Use meaningful element names, a small set of CSS variables, and comments only where the reason is not obvious. Avoid minification in the review copy.

When dependencies are necessary, pin exact versions and explain what each provides. Prefer browser-native behavior for simple interactions. Test with a cold cache and in a clean profile so an extension, service worker, or locally cached package is not silently making the demo work.

Make failure states part of the prototype

Include loading, empty, partial, validation, permission, and network-failure states that affect the decision. A happy-path screen often hides the hardest layout and language questions. Use controls to delay or fail sample requests, and ensure the reviewer can recover without reloading. Long names, translated labels, and narrow viewports should remain usable.

If an action is simulated, label the result clearly. Do not let a fake “Delete” control appear to modify production data, and do not request real credentials. External links should show their destination and open safely.

Test the public boundary

Assume anyone with the URL can copy and inspect the artifact. Remove secrets, internal hosts, customer data, analytics identifiers, and private issue context. Run interactive user code in an isolated iframe, keep it off the application origin, and disable navigation, forms, downloads, and popups unless the demonstration requires them. Provide a trusted report action outside the preview.

Open the link while signed out, on another browser, and after clearing storage. Inspect the network panel for failed or private requests. Test keyboard navigation, 200-percent zoom, reduced motion, and at least one narrow viewport. These checks reveal whether “shareable” means portable or merely accessible from the author’s machine.

Close the review loop

Collect feedback against named questions and record decisions near the artifact. Note what changed, what remains intentionally incomplete, and which prototype shortcuts must not reach production. Give owned demos a deletion path and set an expiration or review date for abandoned links.

A strong shareable prototype is a compact experiment: stable inputs, observable behavior, explicit constraints, and a safe public boundary. Its value comes from reducing ambiguity for the next decision, not from imitating every surface of the final product.