HTML Tips & Tricks: Single-File Prototypes

If there's one thing I hope you take from my Design Outlook 26 talk, it's this: capture ideas as small, single-file HTML prototypes. It's the keystone habit that ties the rest of my process together — a tiny artifact you can play with, reason about, share, and iterate.

I came to this after years of collecting things — magazines cut into folders, images saved from the web, and lately a mountain of Twitter bookmarks. The problem was that a bookmark can't really represent a complex AI idea. It doesn't give you momentum. A single HTML file does.

Why one file?

The magic is in the constraint. Because a prototype is literally one .html file on your computer:

• It's easy to reason about — everything is in one place, no build step, no dependencies.
• It's easy to duplicate — copy it to make a v2 and try a different direction without fear.
• It's easy to share — drag it into Slack, or deploy it with Cloudflare Drop and send a link in seconds.
• It's easy to revisit — pull it back out when a new model or technique lands.

The process

I jump into an agentic workspace like Cursor and talk to the agent — usually with my voice. I'll take an idea I've seen and say something like "replicate this into one HTML file so I can understand how it works and experience it." Then I explain, in detail, what I like about the idea and what I don't.

What comes back is something I can actually play with and reason about — and again, it's just one file on my computer. Not an app, not a service. A file.

Tips & tricks

• Work out what an idea needs before you build. Some prototypes run straight from a file; others need an API key, a tiny local server, or a little relay to reach an AI service. Ask the agent to spell that out in plain language up front — a surprise error at run time is how prototypes die.
• Keep API keys out of the file. Never let a key get baked into the code. Ask for a small settings panel instead, so keys are pasted into the browser and stored there — and the file itself stays safe to share.
• Copy what already works. When a new idea needs an API an older prototype already talks to, point the agent at the working file and say "do it like this." Verified working code beats anything a model remembers — especially model names and API details, which go stale fast.
• Make errors human. Ask the agent to translate raw API errors into plain advice — "your key was rejected, re-paste it in settings" instead of a cryptic 401. It's the difference between a prototype you fix and one you abandon.
• Plan strong, tweak fast. Start with a strong model like Opus or Fable to plan the prototype and get the structure right, then switch to a fast model like Composer 2.5 to tweak the UI. The heavy thinking happens up front; the iteration after that should feel snappy.
• Can't decide between two interactions? Ask for both. Have the agent build two sibling files and pick by feel. Choices like this are defaults to iterate on, not commitments.
• The browser is the test. Before calling anything done, open the file and run the main flow end to end with a real key. There's no test suite for these — the browser is it.
• Build a neighborhood. I stash my files into something I call Tooltown — collections that populate into neighborhoods over time, each with a story about how it evolved.

Cut through the hype

The reason this is material to me: at work we'll have conversations about a concept or a UI or UX idea, and often enough I can whip out one of these files and say "oh, do you mean this?" In a space that moves this fast, having some pre-baked thinking ready to go keeps momentum up.

It's also a great way to test whether an idea actually holds up. Sometimes something that looks brilliant as a Twitter post doesn't work when you try to rebuild it — and understanding that gap is one of the most useful things you can do to navigate the AI space.

So give it a crack. Build out a collection of little HTML files on your computer — sketches and concepts you own — and see if it becomes a keystone habit for you too.

The Gemini collection

Want a head start? I've put together a collection of individual Gemini capabilities, each created in a single file. It's meant to be something you can riff off: pick up one of these files and turn it into something different, playing around with that specific AI capability. Grab one, open a fresh conversation with an agent, and start iterating.

Give your agent the skill

I've also packaged the practice above into a portable skill. Drop it into Cursor (copy the file to .cursor/skills/html-prototypes/SKILL.md in your project, or ~/.cursor/skills/... for every project) and it steers the agent with a shared understanding that you might be non-technical. Instead of jumping straight to code, it helps you gather your requirements first — working out what an idea will actually need (API keys, a little server, a proxy) and telling you in plain language before anything gets built.

Want the full story? Read A Day in the Life of a Design Engineer.