Storing prototypes from external tools

Kadhir Mani

(13 minutes)

<section data-section-id='046447e5-76a0-4a19-8dbf-2eb757fa14ec'><collapsible-card data-icon="file-text" data-title="TL;DR results">After testing thirteen prototyping platforms, here's the full picture we saw + a visualization on file size (y-axis in kb):<bar-chart data-height="450"><bar-line value="3.2" color="#22C55E">ChatGPT</bar-line><bar-line value="205" color="#22C55E">Claude</bar-line><bar-line value="270" color="#22C55E">Gemini Canvas</bar-line><bar-line value="288" color="#22C55E">Bolt</bar-line><bar-line value="293" color="#22C55E">Lovable</bar-line><bar-line value="497" color="#22C55E">Replit</bar-line><bar-line value="1334" color="#F59E0B">Figma Make</bar-line><bar-line value="74.3" color="#EF4444">V0</bar-line><bar-line value="487" color="#EF4444">Hostinger</bar-line><bar-line value="960" color="#EF4444">Anything</bar-line><bar-line value="3500" color="#EF4444">Canva Code</bar-line><bar-line value="0" color="#EF4444">UX Pilot</bar-line><bar-line value="0" color="#EF4444">Base44</bar-line></bar-chart>Green = self-contained HTML achieved, Amber = requires HTTP server, Red = not achievable</collapsible-card> </section> <section data-section-id='63a56c77-0f8e-47d9-ad2a-aab0f8f667d1'><h2 id="background">Background</h2>Prototypes are one of our favorite ways to work. They're surprisingly fun to build, and they're far more information-dense than a doc or a whiteboard session. A new way of communicating, honestly. And right now, there are so many tools to build them with: Claude, ChatGPT, Lovable, Bolt, V0, Replit, and a dozen others can all spin up a working UI in seconds. We've tried many of them, but we kept running into the same issues:<ul><li value="1">Every tool locks your prototype inside its own environment</li><li value="2">Sharing means sending a link that sometimes requires an account, or a live URL that may disappear</li><li value="3">Version control is a pain, especially when we're trying to get feedback</li></ul> For example, one of us wanted to try a few different button-layout configurations, light reorganizing, nothing fancy. Clone the prototype to make multiple versions side by side? Send each one to the team for feedback? Give each its own URL? We ended up using one prototype, taking screenshots, and pasting them into Slack. That setup sucks and defeats the point of doing this in the first place. Honestly, we wanted something simpler: a single, self-contained HTML file. No dependencies, no login, no cloud. Something we could save, open offline in any browser, and expect to work forever. That's a lot easier to share around, and it lets us snapshot the same prototype over time to see how it evolves. <callout icon="target" color="#8B5CF6">Here's the bigger reason we care: a self-contained HTML file is also what makes it possible to store prototypes in our Knowledge Warehouse and make them queryable by agents, things like "find me the prototype that looks like X" or "does Y." That's the real motivation behind this extraction work.</callout>Ideally, we can create a prototype in any tool, point our platform at it, and get a saved snapshot. That way, we get the nice UX of these prototyping tools while still getting an easy-to-share, easy-to-manage, agent-queryable artifact. Long story short, we got it to work. Mostly, but holy moly, it was a real pain to get here. The spread alone tells the story: ChatGPT handed us a clean, tiny self-contained 3.2 KB file out of the box, while Canva generated a bloated 3.5 MB bundle that still couldn't run offline. And that's just the file size, we learned a lot more about how each platform works along the way. This post walks through what we had to do and what we learned about each platform. As a fun bonus, you'll get to see how various prototyping applications interpreted the same request 😄. </section> <section data-section-id='4a0d30be-d06a-4b4c-9f4c-d3410031bf16'><h2 id="setup">Setup</h2>We used a single, consistent prompt across all tools:<callout icon="rocket" color="#8B5CF6">"Let's build a fun little todo application. I want it to be galaxy themed, easy to understand."</callout>Why this prompt?<ul><li value="1">TODO app<ul><li value="1">Universal reference point, lots of examples out there</li></ul></li><li value="2">Fun + Galaxy themed<ul><li value="1">Room for interpretation, visual flair, creative rendering</li></ul></li><li value="3">Easy to understand<ul><li value="1">Should keep the complexity low, making self-containment easier</li></ul></li></ul> What we're evaluating in the output:<ul><li value="1">Can the result be extracted as a single, self-contained <code spellcheck="false" style="white-space: pre-wrap;">.html</code> file that opens in any browser with no network required?</li><li value="2">How big is our resolved HTML file?</li></ul> Note: we'll refrain from outright ranking the platforms against each other since they all have their own strengths and weaknesses. </section> <section data-section-id='73d23766-2299-4d16-bcd4-cb72e2ef6fa9'><h2 id="claude">Claude</h2>Right off the bat, we ended up with two weird problems:<ul><li value="1">Sometimes Claude gave us a TSX / JSX file, other times it gave us an HTML file<ul><li value="1">We never figured out a reliable way to understand when Claude would generate one over the other </li></ul></li><li value="2">The HTML files did not render identically to the Claude UI</li></ul> We liked that it gave us a nice, simple file, but the file wasn't self-contained. So we had to do two things:<ul><li value="1">TSX / JSX, throw that into an isolated bundler on our server, which compiled it into an HTML file<ul><li value="1">Took a bit of iterating, but we ended up using esbuild with some base configurations for this</li></ul></li><li value="2">The HTML was weird, turns out it needs a bunch of CSS variables to render correctly<ul><li value="1">Which fortunately, Claude was kind enough to generate that file for us - attaching it here in case it helps anyone else</li><li value="2">This goes into the final HTML file in a style tag, as required</li></ul></li></ul> <file-upload data-src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=55e3f8b6-c2c0-42ed-a07a-973db04b301b" data-file-name="claude-widget-host.css" data-description="" data-file-type="text/css"></file-upload>And with those two problems solved, presto!<h3><iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=79fcac6e-fedf-4f5f-979c-a8fc32d468ef" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>HTML file achieved ✅️, size = 205 kb</h3> </section> <section data-section-id='68d3f281-18b2-478a-817d-1e064b709ae6'><h2 id="chatgpt">ChatGPT</h2>Super straightforward, downloaded as an HTML file, and came out fully resolved out of the box. No changes required. No weird bundling, actually self-encapsulated ⭐️:<h3><iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=1fe6eb99-456f-45e6-ad02-52fa2c07c91b" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>HTML file achieved ✅️, size = 3.2 kb</h3>So tiny! So exciting! </section> <section data-section-id='17c47791-2f1e-4db9-ad80-7a76f1d4ab03'><h2 id="gemini-canvas">Gemini canvas</h2>Gave us a TSX file, which okay no problem, we did this for Claude already, should work out of the box. Except in one of our runs, it also included the lucide icon library, and it required tailwind to render correctly. Which we'll admit made the output TSX file super token efficient, but did complicate our build system here. No problem, we can add this to our bundling step. In the end, we pull in a set of allowlisted dependencies (like lucide, date-fns, lodash-es, etc) and give esbuild access to those node_modules at compile time. Note, we only allow a small set of trusted packages, so random, uncontrolled imports can’t slip in. Can't be too careful these days with the sheer number of vulnerabilities being pushed. Next, the tailwind classes are scanned out of the source and compiled into CSS using @tailwindcss/oxide and @tailwindcss/node. Then everything is inlined into one final HTML file for us. And terrific, now we can support Gemini canvas:<h3><iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=d83dec1f-06d9-4ac5-a71d-2dc40a1df78f" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>HTML file achieved ✅️, size = 270 kb</h3>Honestly, have to say integrating lucide and tailwind is pretty cool. It allows for a higher level of output token efficiency. In other words, for each output token, by leveraging these external libraries, we can get "more frontend" out of it. </section> <section data-section-id='0e392b0f-2b85-4733-bcdf-9d148e5eac6e'><h2 id="lovable">Lovable</h2>Next, we get into the gnarlier platforms. The model providers are great because they give us a single file to begin with; they're not in the business of hosting stuff. But Lovable (and others) are in the business of hosting things, so they give us a link instead. So the question is, how can we convert a hosted link into a single file for our purposes? At a high level, we act like a browser and:<ol><li value="1">Fetch the HTML</li><li value="2">Download the CSS and JS that are requested from the same server</li><li value="3">Bundle it all together into a single HTML file</li></ol> It roughly worked, but in our particular application here at Lovable, it looks like it also used an image that it was failing to fetch. So we grabbed that as well, converted it into a base64, and threw that into the final HTML. Perfect. We get our resolved file:<h3><iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=befaf16e-1c4d-4f01-ab9f-85af2894fa83" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>HTML file achieved ✅️, size = 293 kb</h3>We also noticed the prototype was trying to access local storage and session storage for metric tracking or something. Also happened on some of the other platforms. We're still not totally sure what it's doing, but it meant our iframes here had to accommodate accordingly. </section> <section data-section-id='83170ad3-edfb-46b0-bbf2-964d1a83421a'><h2 id="replit">Replit</h2>Worked similar to Lovable - looks like it's some sort of a Vite-based SPA. Easy to grab and compile everything, very predictable structure:<h3><iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=2d4f3738-fbd7-476f-b0c2-dbe9f4aa672d" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>HTML file achieved ✅️, size = 497 kb</h3>Though this file was a tad larger than I was expecting. Inspecting it, it has <a href="https://bundlephobia.com/package/@radix-ui/themes@3.3.0" rel="noreferrer">Radix</a>, <a href="https://" rel="noreferrer">TanStack query</a>, <a href="https://bundlephobia.com/package/lucide@1.17.0" rel="noreferrer">lucide</a> icons embedded into it. Must be some of the defaults Replit uses to create, would explain the larger size compared to Lovable. Similar to Gemini canvas, the output tokens from the model will have higher efficiency through this method, though the resulting bundle size and complexity take a hit. Probably worth it? Also you need less tokens which we like, less room for the models to mess it up. </section> <section data-section-id='ef146b2b-b5d5-4e37-9523-fa71c14c64bb'><h2 id="v0">V0</h2>Vercel has the benefit of maintaining NextJS and Turbo. We expected them to lean into their technologies when assembling prototypes. And sure enough, even for our simple TODO application, it relies on an API layer running on a NextJS server. We needed to rewrite the <code spellcheck="false" style="white-space: pre-wrap;">_next</code> chunk fetches back to the original application server so the lazy-loaded rendering worked. In other words, the final HTML file still references Vercel's CDN at runtime, so even the frontend isn't a self-contained file, unfortunately. You'll notice the state management doesn't work:<h3><iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=4932c7fb-03a1-4eda-9206-acf3ed675194" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>HTML file not achievable ❌️, size = 74.3kb</h3> </section> <section data-section-id='dc1f73ea-d1e6-46cb-be8b-51b3ad0b008e'><h2 id="figma-make">Figma make</h2>This one was weird, it did not work out of the box with the setup we had so far. Looks like Figma make pages aren't self-contained SPAs, they're HTML shells around their SitesRuntime. If you inspect the raw HTML from the public Figma make:<pre spellcheck="false" data-language="html" data-highlight-language="html"><script type="module"> import {SitesRuntime} from '/_runtimes/sites-runtime.XXXX.js'; const sitesRuntime = new SitesRuntime({ container: document.getElementById('container'), env: 'published', bundleId: 'XXX', loadComponentsOverNetwork: true, assetsVersion: 'v11', fontsVersion: 'v1', videosVersion: 'v1', codeComponentsVersion: 'v2', withBaseStyles: false, reportingDomain: "https://www.figma.com", bundleCreationDate: '2026-06-09 22:48:02 UTC', isFigmake: true, enableMetaTags: true, renderOptions: { metronomeEnabled: false, transform3dEnabled: false, }, }); </script></pre> We ended up faking the Figma runtime to get it to resolve the HTML. We managed to bundle that together, but ran into a few headaches. Namely it's loading components, API calls, and JSON files through a dynamic <code spellcheck="false" style="white-space: pre-wrap;">import( )</code> . We needed to go download those files to disk temporarily, and register them in a bootstrap script in the HTML's header. If you look inside the resulting HTML file, you'll see a <code spellcheck="false" style="white-space: pre-wrap;">registerModuleImportMap</code> that does the registration for the import calls. In effect, we're faking the Figma runtime to get it everything it needs, but it's not perfect unfortunately. There are two constraints the file has to satisfy to run correctly:<ol><li value="1">It needs an HTTP origin. The import map uses absolute paths (e.g. <code spellcheck="false" style="white-space: pre-wrap;">/</code>), so it must be served over HTTP/HTTPS — not opened as a local <code spellcheck="false" style="white-space: pre-wrap;">file://</code> URL. Without an origin, <code spellcheck="false" style="white-space: pre-wrap;">replaceState</code> can't fake the root route and routing breaks.</li><li value="2">The bootstrap must complete before any imports resolve. Our fetch-patching code runs as part of the bootstrap script. If the browser starts resolving module imports before that script finishes, the patches aren't in place yet and network calls go uninterrupted.</li></ol> Together, these mean you can't open the file locally, but serving it through an HTTP server (like our platform) satisfies both constraints and works great: <iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=04bf2e7b-a2b3-4747-b393-f2e371878d64" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>For our purposes here, we'll consider that mostly a win, unfortunate that it doesn't work offline:<h3>HTML file achieved ✅️*, size = 1,334 kb</h3>*assuming you can host the file on an HTTP server </section> <section data-section-id='b5b3ff12-53b6-4971-849d-aa84f81c83fa'><h2 id="bolt">Bolt</h2>Easy, same Vite-based SPA setup as Lovable and Replit. Worked out of the box with the existing pipeline:<h3><iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=4c2a0ced-2c46-436c-8296-e191cc2704d0" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>HTML file achieved ✅️*, size = 288 kb</h3>Inspecting the HTML file, Bolt is calling out to supabase with some default credentials baked in client side. We originally inspected it because we noticed it would take an unusually long time for the initial load. That was a tad surprising, guess it's using that to store our TODOs? Won't work offline, but at least self encapsulated. *assuming you have network access We were originally sketched out about client side credentials, but looks like that's <a href="https://www.reddit.com/r/Supabase/comments/rwdrlo/how_is_it_secure_to_use_supabase_on_the_client/" rel="noreferrer">intentional</a>. </section> <section data-section-id='20e2733d-bf8e-41fa-8019-f2a6de6a5543'><h2 id="canva-code">Canva code</h2>This one was a real pain. Canva hosted apps have three layers as far as we can tell:<ul><li value="1">A shell page that loads some massive webpack bundles<ul><li value="1">which also loads a <code spellcheck="false" style="white-space: pre-wrap;">window.bootstrap</code> JSON blob that describes the design</li></ul></li><li value="2">A codelet iframe where our actual application lives</li><li value="3">Canva chrome footer, reporting errors, heartbeat polling, and metrics</li></ul> Long story short, we ran into <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS" rel="noreferrer">CORS</a> and <a href="https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity" rel="noreferrer">SRI</a> issues that forced us to inline the shell server-side, string-patch the footer fetches, globally rewrite the <code spellcheck="false" style="white-space: pre-wrap;">_assets/</code> paths its trying to load back to original Canva code app, and patch dynamic script/link/iframe creation so lazy chunks also go back to the Canva app - similar to V0. Definitely not a self-contained file:<collapsible-card data-icon="file-text" data-title="Open to see" data-default-collapsed="true"><h3><iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=b805a4ec-4eef-4e81-876a-dcc9be87e5a7" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe></h3></collapsible-card>Note: closed by default to prevent autoscroll <h3>HTML file not achievable ❌️, size = 3.5 mb</h3>MB!! So big my god. And requires more dynamically loaded code to run 😱. Maybe we'll do a follow up post going through all the things we learned about how Canva code works one day. </section> <section data-section-id='daa6ab6e-3244-4a24-8c70-4b9cdb1a1e3b'><h2 id="anything-com">Anything.com</h2>Looks like this one leverages a lot of Next.js, so there's an API route here (on the backend server) that we can't do anything about. But on top of that, there were many CDN chunks. We ended up rewriting the page-origin assets back to the original created.app and used an embedded Bootstrap script, so at runtime the /_next/ asset also loads from the original CDN. Means we can't get a self encapsulated HTML file, we still call back to anything.com's servers:<h3><iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=39573d25-b9b0-45cc-a352-bd4a473c9a39" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>HTML file not achievable ❌️, size = 960 kb</h3> </section> <section data-section-id='92cb76c6-0cdd-4188-9afc-4fd144542159'><h2 id="base44">Base44</h2>Immediately ran into an issue where Base44 wanted us to login before it would let us do anything. We can't load this thing in the server context, can't even see if we can make it self-encapsulated Here's the prototype it generated:<collapsible-card data-icon="file-text" data-title="Open to see" data-default-collapsed="true"><iframe src="https://orbit-task-labs.base44.app" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe></collapsible-card>Note: closed by default to prevent autoscroll <h3>HTML file not achievable ❌️</h3> </section> <section data-section-id='f744b081-c794-42e5-9d72-915711b5b0cd'><h2 id="ux-pilot">UX pilot</h2>This one was strange for what we're trying to do. The public link UX pilot gives us isn't an app, it's like a set of slides. On top of that it required us to login before it let us do anything. Non-starter for our self-encapsulation, probably doesn't belong in this category honestly:<h3><iframe src="https://uxpilot.ai/s/7aae543942d5a06dcf4fa83713947ea2" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>HTML file not achievable ❌️</h3> </section> <section data-section-id='941f030a-adde-455e-a655-c4dfceeb61e8'><h2 id="hostinger-horizons">Hostinger horizons</h2>This one ran into the same issue as V0, there are some backend APIs it requires for even our simple TODO application. So it's not possible to fully self encapsulate, but we wanted the frontend piece at least. As we kept digging further, looks like hostinger uses the domain suffix for: horizons apps, parked domains, their website builder application, and legacy PHP uploads. Meaning even figuring out if this is a page we can bundle was a bit of a hassle, along with which links to load into our final file. But once we figured that out (we only let Vite <code spellcheck="false" style="white-space: pre-wrap;">/assets</code> through), then the standard Vite-based SPA setup did the trick for the frontend only (you'll notice the state management doesn't work):<h3><iframe src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=1bc9fee9-1f96-4374-a963-c682f58d2c02" style="width: 100%;" height="400" frameborder="0" allowfullscreen="true"></iframe>HTML file not achievable ❌️, size = 487 kb</h3> </section> <section data-section-id='9886b4df-f733-4941-88b0-e7e33b7f4377'><h2 id="take-aways">Take-aways</h2>After testing thirteen prototyping platforms, here's the full picture we saw + a visualization on file size (y-axis in kb):<bar-chart data-height="450"><bar-line value="3.2" color="#22C55E">ChatGPT</bar-line><bar-line value="205" color="#22C55E">Claude</bar-line><bar-line value="270" color="#22C55E">Gemini Canvas</bar-line><bar-line value="288" color="#22C55E">Bolt</bar-line><bar-line value="293" color="#22C55E">Lovable</bar-line><bar-line value="497" color="#22C55E">Replit</bar-line><bar-line value="1334" color="#F59E0B">Figma Make</bar-line><bar-line value="74.3" color="#EF4444">V0</bar-line><bar-line value="487" color="#EF4444">Hostinger</bar-line><bar-line value="960" color="#EF4444">Anything</bar-line><bar-line value="3500" color="#EF4444">Canva Code</bar-line><bar-line value="0" color="#EF4444">UX Pilot</bar-line><bar-line value="0" color="#EF4444">Base44</bar-line></bar-chart>Green = self-contained HTML achieved, Amber = requires HTTP server, Red = not achievable Model providers are the most portable. Claude, ChatGPT, and Gemini hand you a file from the start. Though the dedicated prototyping platforms are nicer to build in. We can still bundle many of them down to a single file though it takes meaningfully more work to do so, assuming your prototype isn't super complex. A few patterns worth calling out:<ul><li value="1">Token efficiency vs. portability tradeoff — Tailwind is a concise way for models to style apps, but it pulls in a CSS compiler at build time and complicates self-containment. Heavy default dependencies (React, Radix, lucide, TanStack Query, etc) compound the bundle size quickly. Though leveraging all of the above can cause the model output token efficiency to be high, less room for it to mess up.</li><li value="2">Two dominant architectures — Frontend-focused platforms (Lovable, Bolt, Replit, Hostinger) almost universally reach for a Vite SPA. Fullstack platforms (V0, Anything) use Next.js, which makes a truly offline bundle essentially impossible — even the "frontend" ends up coupled to a server through lazy loading chunks, etc.</li><li value="3">Login walls are a hard blocker — Base44 and UX Pilot couldn't be evaluated in a server context at all. Public-accessible output is table stakes for self-encapsulation at scale.</li></ul> <feedback data-feedbacknodeid="d79168f0-313c-424b-af63-2683b51b3394" data-title="Any prototyping platforms we've missed?" data-datatype="TEXT" data-metadata="{"type":"TEXT"}" data-description="We'll try them in the next post!"></feedback> Side note, we've made this functionality free on the platform. Just start a blank doc, add a prototype node, and select "snapshot" in the upload dialog. You can download the HTML after its done processing. Still more edge cases we're actively patching. Shoot us a note at support@productnow.ai if a prototype is giving you trouble! <img src="https://api.productnow-prod.com/storage/getStorageObject?storageObjectId=9f1d0807-c970-4800-b26e-df2a29d6d969" alt="9f1d0807-c970-4800-b26e-df2a29d6d969" data-alignment="center" data-card="true" width="378" height="530"></section>

Published

June 11, 2026

Keep reading

The Context Engine

Every company now has thousands of agents trying to get work done, and almost none of them know what the organization actually knows. Organizational context is a big data problem with its own 4Vs. What a context engine is, the five attributes that define one, and why ProductNow built it as a plain document editor.

AI-native data integration without an ontology

Every data integration effort historically required an ontology — slow to build, locking clients out of their own system, never truly self-service. AI changes that equation: continuous ingestion into living documents, agent-managed pruning, and a deep graph — integrations in 24 hours, not months.

CRDTs are not enough when your co-worker is an AI agent

CRDTs converge; they do not coordinate. That distinction becomes critical the moment an AI agent joins the editor. Why multiplayer collaboration needs a coordination layer above merge, and the section-level lease protocol we built to keep agents well-mannered.