How Stitch Actually Works — And the Steps I Followed The previous post introduced Stitch as "an AI that redesigns your site through conversation." That description is accurate but abstract. This post gets concrete — the exact steps followed to redesign JSLipi using Stitch, including what was typed, what came back, and how the iterations unfolded. Step 1: Paste the Live URL The starting point is stitch.withgoogle.com. There is no upload, no export from Figma, no code to paste. Just a live URL. Stitch fetches the site and analyzes it — the page structure, existing color palette, layout sections, typography choices. Within a few seconds, it renders a redesigned version of your own site directly in the browser. For JSLipi, the input URL was the live homepage. Stitch loaded it, read the dark/light theme structure, identified the blog card grid, the series section, the header — and produced a first-pass redesign automatically, before a single chat message was sent. Step 2: The First Output The automatic first output is rarely the final design, but it sets the direction. Stitch's initial redesign for JSLipi had: Cleaner card layouts with better spacing A more prominent hero section Slightly adjusted typography hierarchy It already recognized this was a blog and made choices appropriate for content-first layouts. Things like Hashnode or Medium clearly influenced the patterns it reached for. The starting point was solid. What came next was a conversation to close the gap between that starting point and something that felt right. Step 3: Chat Instructions for Refinement This is where Stitch becomes genuinely useful. Instead of manually adjusting margins in a visual editor, you describe what you want: > "Follow popular blog design patterns. Maintain dark and light theme support." Stitch updated the output — better visual hierarchy, cleaner section separation, design choices consistent with well-known developer blogs. More messages followed: > "Make the hero section cleaner. Reduce visual noise." > "Card grid should feel more editorial — less grid, more flow." > "Increase contrast in dark mode. The text feels flat." Each message produced an updated HTML/CSS output. Not a pixel editor — a conversation. The design gets refined with words, not clicks. Step 4: Iterating to a Final Version Per Page The same process was repeated for each page of the blog: Page Reference File ------ --------------- Home Blog listing Blog series About us Contact For each page, the process was: start a new Stitch session → paste URL → describe what the page should feel like → iterate → save the HTML output. Each session typically involved 3–6 chat messages before the design reached a point worth saving. The dark theme variants were also refined, with messages specifically addressing color contrast, subtle background layering, and card shadow depth. Step 5: Save the HTML Reference Files When each page design felt right, the full HTML output was saved. These files were not cleaned up or restructured — they were saved exactly as Stitch generated them: raw HTML with inline styles and embedded CSS. They were stored in inside the project: These files were not deployed. They were reference material — a visual specification showing what the actual React app should look like after implementation. What Stitch Is Not A few honest observations: Stitch does not write React code. The output is static HTML. Turning it into component-based JSX is a separate step. Stitch does not know your component logic. It redesigns the layout and styling, not the functionality. The output needs human judgment. Some design choices Stitch made did not fit JSLipi's tone or brand. Those were ignored. The saved HTML files are design references, not deployment-ready code. The next step — translating those references into actual React components — is where Copilot comes in. ✅ Summary The Stitch workflow for JSLipi followed five steps: paste the live URL, review the automatic first redesign, refine through conversational chat messages, repeat per page, and save each final HTML output as a reference file. The result was five HTML files in representing the target design for each major page. The next post covers how those files were handed to Copilot to drive the actual React implementation.