I Built a Product Demo With Gemini. Here’s What Survived the First Edit.
The color swap worked. The 390px crop and made-up product claims still need a human handoff.AI-generated concept showing blue and ivory projector proofs beside a cropped phone view.The projector turned warm ivory after I’d asked for one edit. On a phone-sized screen, part of its body was still cut…
The color swap worked. The 390px crop and made-up product claims still need a human handoff.AI-generated concept showing blue and ivory projector proofs beside a cropped phone view.The projector turned warm ivory after I’d asked for one edit. On a phone-sized screen, part of its body was still cut off at the left edge. The controls still worked.I’d asked Gemini to build a one-file, interactive demo for a fictional pocket projector. The first edit kept the controls working, but it didn’t make the page ready to show as a finished product.If you need an AI-made page you can keep changing, the first render is only the start. Below are my exact prompts, the two downloaded files’ results, and the rule I’d use before handing a demo over.The first render worked until the phone got involvedOn September 18, 2026, I used the 3.1 Pro option visible in the signed-in Gemini app, with Canvas selected. The account already had Pro access. I made two requests with no retries. New cash spending was USD 0.00. That doesn’t make this a free-tier test.The product, Nookbeam, isn’t real. I wanted a portfolio-style launch preview: a projector, a beam, two scenes, and two shell colors. No checkout, prices, testimonials, or borrowed product photos.Google’s Canvas help describes the code-and-app workspace; what follows comes from the HTML I downloaded and the controls I operated, rather than the help page’s feature list.At 1440px, the result put the controls in a dark panel beside a large illustration. Cobalt changed the projector body to blue-gray; Graphite made it darker. Living Room Film showed a muted projected image. Balcony Stars replaced it with a star field.The button outlines moved with each choice, and the selected state changed in the page’s accessibility tree as well. I clicked all four color-and-scene combinations on desktop.Then I set the viewport to 390px. The panel stacked above the illustration, and I could still use both kinds of control. But the illustration cropped the projector on its left edge.The light cone and projection surface survived; the device itself, which I’d explicitly made the visual focus, didn’t fully fit. A phone reader would see the controls first, scroll down, and find part of the subject missing.A working button isn’t a finished mobile layoutThe downloaded SVG uses preserveAspectRatio="xMidYMid slice". That setting is consistent with what I saw: the art fills its box by trimming the edges. It isn't, on its own, proof of every layout cause. It is a good place to inspect before accepting the page.What changed, and what carried overThe brief asked for controls, not a static mockupMy baseline prompt made the handoff testable. I specified one HTML file, inline CSS/SVG/JavaScript, and no outside assets. That kept the output portable enough to download and inspect.I also asked for visible and aria-pressed selected states, so a pretty pair of dead buttons couldn't pass as an interactive demo.Nookbeam was fictional from the start. The prompt also barred unsupported specifications. Here is the complete input I sent to Canvas:Exact prompt used · baselineThis is a portfolio/launch-preview concept, not a checkout page. Product line: “Turn any quiet corner into a screen.” Provide two projected scenes: “Living room film” and “Balcony stars”. Provide two projector-shell colors: “Cobalt” and “Graphite”. Each scene and shell-color control must actually change the SVG illustration, and the selected option must be visually obvious and exposed with aria-pressed. All visible copy must be in English.Build one original, self-contained interactive product demo as a SINGLE HTML file for a fictional pocket projector called Nookbeam. Return the complete HTML, including all CSS, SVG art, and JavaScript inline. No React, packages, external images, external fonts, libraries, network calls, or separate files. Do not use a real brand or make unverifiable technical claims.Make the projector and its beam the visual focus. Show a believable device body, light cone, and projection surface; give the two scenes distinct atmospheres without depending on external assets. Keep the layout legible and usable at both 1440px desktop width and 390px phone width. Include a short product description and concise, functional control labels. Avoid placeholder lorem ipsum, fake testimonials, fake prices, and unsupported specifications.Please output a single complete HTML code block that I can copy into one .html file and open locally in a browser. Do not omit code or replace any section with comments like “rest of CSS here”. After the code block, state only whether you used any external dependency.The file arrived as a complete download, with the styles, art, and button logic inline. But the copy slipped past the constraint. It described “sharp focus in tight spaces” and projecting onto “irregular surfaces.”There is no real projector behind this mockup to support either claim. I wouldn’t leave those lines in a public-facing product page just because the code runs.One ordinary edit kept the interaction intactI kept the second request to one color option and one short line. No rerolls. I didn’t ask Gemini to redesign the page or try a menu of variations. The prompt also told Canvas what had to survive:Exact prompt used · revisionRevise the exact single-file Nookbeam HTML you just generated. Change the “Cobalt” shell-color option to “Warm Ivory” and update the short product line from “Turn any quiet corner into a screen.” to “Bring movie night wherever you land.” Preserve the “Graphite” option, both projected scenes, clear selected-state feedback, working controls, English copy, and a usable 390px phone layout. Keep everything in one self-contained HTML file with inline CSS, SVG, and JavaScript and no external dependencies. Do not redesign unrelated parts or remove functionality. Return the complete revised HTML in one code block; do not summarize or omit unchanged sections.The downloaded before-and-after files show a narrow change. The Cobalt label, swatch, color variables, SVG gradient references, JavaScript key, and default selection became Warm Ivory. The product line changed exactly as requested.Graphite and both scenes stayed in the file. I operated their controls again at desktop width and at 390px; they still changed the illustration and selected state.The edit preserved behavior, including the old defectsWarm Ivory made the device lighter and easier to distinguish against the dark panel. It didn’t repair the phone crop. The unsupported description stayed word-for-word, too.The baseline had asked for a usable phone layout and no unverifiable specifications; those instructions weren’t enough. The revision preserved the working parts, but it didn’t resolve the original defects.I checked every shell-and-scene combination on desktop in both files. On mobile, I operated three combinations in each file, including both scenes and both shell controls. No button went inert in those checks.This is one bounded demo and one edit, not a claim about every Gemini build or a full accessibility audit.A successful edit can preserve the bug you meant to catch later.I’d repair this before showing it as a product pageThe tempting move is to call the revision done because the visible request landed. My call is repair. The HTML is worth keeping as a working concept, and the new color didn’t break the interactive paths.But the mobile crop weakens the main visual, and the technical-sounding paragraph gives a fictional object capabilities nobody has verified.I would change the SVG composition so the whole device remains visible at 390px, replace the capability claims with conceptual copy, and check the controls again. Those fixes are work still to do; they aren’t part of these two untouched Gemini files.If you’re making a page that will be revised more than once, use this handoff rule:Keep the AI file when the requested edit lands, every required control still responds, and the desktop and phone compositions both show the subject clearly.Repair it when the core interaction works, but a concrete visual or copy defect remains. That’s where this Nookbeam demo sits.Drop or rebuild when a required scene or option stops working, or when the file can no longer be saved and inspected as the promised one-file deliverable. I didn’t observe either failure here.The first render gave me something real to inspect. The second proved that a small edit could survive without dismantling the controls. The page still needs a human finish before anyone treats it as a product presentation.This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!I Built a Product Demo With Gemini. Here’s What Survived the First Edit. was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.Source: Generative AI Pub — Published — Category: Image AI