DEV Community: Yassine

I Tested Shopify 3D Product Media Before Touching My Theme

Yassine — Fri, 07 Aug 2026 17:32:46 +0000

I was about to add a new product-media block to a Shopify theme when I stopped myself. The thing I actually needed to prove first was much smaller: could a shopper rotate the product, understand its shape, and get a useful result on a real product page?\n\nThat distinction saved me from turning a 3D experiment into a theme project. I used Supra 3D Capture to turn a guided set of phone photos into a web-ready GLB, then treated Shopify-native publishing as the last step—not the first. Here is the workflow I now use before I touch Liquid, a theme setting, or an app block.\n\n\n\n## The test I wanted to pass\n\nI was not looking for a cinematic asset. I wanted a model that made an ordinary product page easier to inspect. For the first test, I choose a compact SKU with clear edges and visible depth: the kind of product where front-and-back photos still leave questions about thickness, curves, or proportions.\n\nThat filter matters. If you are deciding where to start, the product-selection ideas in Which Shopify Products Should You Turn Into 3D Models First? are a useful sanity check. I avoid reflective, translucent, or fuzzy items for a first capture because they introduce scanning variables before I have learned the publishing path.\n\nMy definition of done was deliberately plain:\n\n- The model rotates smoothly on a phone and desktop.\n- Its silhouette still makes sense at a small size.\n- The texture does not hide important product details.\n- I can attach it to Shopify product media without building a custom viewer.\n\nIf it fails one of those, I go back to capture. I do not try to code around a weak asset.\n\n## Step 1: Make the photo orbit boring\n\nThe capture part is the least glamorous piece, and it has the biggest downstream effect. I put the product in even light, keep the background simple, and slowly move around it while keeping roughly the same distance. Supra 3D Capture guides the session as I collect 10 or more phone photos, then sends the set through its photogrammetry pipeline.\n\nThe useful mental model is not ‘take pretty product photos.’ It is ‘give reconstruction enough overlapping views to understand every surface.’ If a side is underexposed or never appears in the orbit, the model cannot invent the missing geometry reliably.\n\n\n\nI now make a quick capture checklist before uploading:\n\n1. Clean the product and remove loose packaging that can shift between frames.\n2. Use diffuse light, so shadows do not masquerade as edges.\n3. Include the top, sides, and the details a customer would inspect before buying.\n4. Keep the product still; move the phone, not the SKU.\n\nThat is enough process for a first run. Specialist gear and 3D software are not the constraint here; repeatable photos are.\n\n## Step 2: Inspect the GLB like an integration artifact\n\nWhen the model comes back, I do not jump straight to the storefront. I rotate it and look for failure modes a normal gallery can hide: melted-looking seams, a missing underside, noisy texture, or a model that is technically complete but visually ambiguous.\n\nThis is where I treat the GLB like any other generated build artifact. A successful output is not automatically ready to ship. I check the angles that matter to a buyer, whether the scale feels plausible, and whether the model remains clear against the product page background. If the model is weak, recapturing is cheaper than debugging shopper confusion later.\n\n\n\nFor larger catalogs, I would make that review explicit. A simple scorecard—product shape, surface difficulty, margin, return risk, and image coverage—keeps the team from spending time on impressive but low-impact scans. The companion guide on building a Shopify 3D capture priority scorecard is a good framework for that decision.\n\n## Step 3: Publish natively before customizing\n\nOnce the GLB passes inspection, I attach it to the Shopify product as media. That is the first implementation path I test because Shopify’s native 3D viewer already gives shoppers the direct manipulation behavior I care about: drag, rotate, inspect. Supra 3D Capture also supports a dedicated Online Store 2.0 theme app block when I need placement beyond the default gallery.\n\nThere is a small but important trade-off here. Native product media is the lowest-friction validation route; a theme app block gives more layout control. I start native because it answers the product question first. Only after I see that the model helps explain the item do I spend time deciding where it belongs in the page hierarchy.\n\n\n\nI test three things on the storefront:\n\n- Does the model load and rotate where the customer expects it?\n- Does it complement the existing photos instead of replacing useful detail shots?\n- Does the mobile experience make the object easier to understand, not just more novel?\n\nThat last one keeps me honest. A 3D model should close an expectation gap—shape, scale, texture, or construction—not become decoration that competes with the buy button.\n\n## What I would do next\n\nMy next move would be to repeat this on three high-question SKUs, then compare support questions, return reasons, and how often shoppers engage with the media. I would not promise a conversion lift from one test, but I would look for evidence that customers can make a more confident choice.\n\n*TL;DR:* I learned to validate the capture and the native Shopify experience before I customize a theme. Start with an easy-to-scan product, make a complete phone-photo orbit, inspect the GLB as a real release artifact, then publish with Shopify-native media or an app block. You can start the same small experiment from the Supra 3D Capture Shopify App Store listing.\n\nHave you found a product category where interactive 3D explains something photos consistently miss?

How I Export Webflow Sites to Static HTML Without Losing CMS Content

Yassine — Fri, 31 Jul 2026 19:34:07 +0000

I kept running into the same problem: a Webflow build would look finished in the designer, then turn into a project with awkward handoff rules the moment I needed to host it somewhere else.

That is why I started paying attention to ExFlow.site. It is a Webflow exporter that lets me download a site by URL, pull down pages, CSS, JS, images, media, and CMS content, and then decide whether I want to host it myself or sync it to Git, S3, or FTP.

Webflow itself is still good at what it does. Its Export clean HTML5 and CSS3 describes a clean HTML/CSS/JS export, and its pricing page makes the limitation plain: exported code cannot be reimported. That matters if you are trying to treat Webflow like a portable source of truth instead of a one-way publishing layer.

The first thing I wanted was not a fancy new design tool. I wanted a predictable export path. In practice, that means knowing whether the site is mostly static pages, whether the asset library is tidy, and whether the content model can survive outside Webflow.

ExFlow is useful because it stays focused on the part Webflow users actually need when the site has to leave the platform. I can export the URL, choose whether CSS, JS, images, and all pages come along, remove the "Made with Webflow" badge when needed, add custom script.js and style.css files, and push the result to Git, S3, FTP, or ExFlow hosting.

That is the point where the workflow stops being theoretical. I am no longer debating whether a site is “exportable” in some abstract sense. I am checking whether I can ship the files, keep the layout intact, and hand the result to whichever deployment target makes sense for the project.

Here is the checklist I use before I export a real site:

I separate pages that are purely static from pages that depend on changing content.
I confirm which CMS content needs a separate handoff plan.
I export with the asset types I actually need instead of assuming every file belongs in the bundle.
I open the result locally and check that the page structure, media, and links still make sense.
I decide where the site should live: Git, S3, FTP, or ExFlow hosting.

That exported-files view is the real sanity check for me. If the file tree looks clean, I know I am closer to a portable site. If it looks messy, I usually stop and fix the source structure before I export again.

A lot of the value here is not just “download the site.” It is the ability to think in terms of deployment targets. A Git sync makes sense when I want reviewable changes. S3 makes sense when I want cheap static hosting. FTP still matters for some client servers. ExFlow hosting is there when I want the simplest path from export to public site.

My rule of thumb is pretty simple. If the project is mostly marketing pages, a landing experience, or a content site that can be flattened without losing its job, exporting Webflow is often the cleaner move. If the project depends on live CMS workflows, ecommerce behavior, or other dynamic platform features, I treat export as one piece of the puzzle instead of the whole answer.

That is also why I have started thinking of Webflow less like a permanent hosting destination and more like a design system with an exit ramp. Once you think that way, the trade-off becomes clearer: keep the parts that need to stay in Webflow, and export the parts that should be portable.

If you want the deployment side of this workflow, I wrote a separate walkthrough on how I exported a Webflow site to Git, S3, or FTP without rebuilding it. And if your content structure is still changing, my notes on how I map Notion fields to Webflow CMS without breaking formatting are the part I wish I had earlier.

TL;DR: Webflow is great for building, but export is what makes it portable. ExFlow gives me a practical way to download the site, keep the useful assets, and choose the hosting path that fits the project instead of forcing every build to stay locked in one place.

If you have ever had a Webflow project get awkward the minute someone asked for self-hosting, what was the part that broke first?

How I Built a Review-First Shopify Blog Automation Pipeline

Yassine — Sat, 25 Jul 2026 03:34:41 +0000

How I Built a Review-First Shopify Blog Automation Pipeline

I was trying to keep a Shopify blog active without turning it into a pile of generic AI posts. I did not want another tool that spit out a draft, published it, and let me discover the problems later. I wanted a workflow that could take real product context, build an SEO-friendly draft, generate matching visuals, and then stop long enough for me to review the result.

That is the part that Supra Blog Automation actually solves for me. It can generate a single post or a recurring automation, use product context, add internal links, create visuals, and either publish immediately or save the post as a draft. For a Shopify store, that is the difference between "content machine" and "content I can stand behind."

The workflow I actually want

My default setup is simple:

Start from a product, collection, launch, seasonal theme, or support question.
Give the post a tone and a goal.
Let the tool build the structure, internal links, and visuals.
Review the draft before anything goes live.

That last step matters. I am fine with automation doing the boring work. I am not fine with it deciding that a shaky claim or a weak CTA is good enough. The review gate is what keeps the output useful. I talked about that exact approach in How I Keep Shopify Blog Drafts Product-Aware and Reviewable, and I still think that is the right default for ecommerce content.

The other thing I like is that the tool does not force a single publishing mode. Sometimes I want an article scheduled because the topic is evergreen. Sometimes I want a draft because the post needs a human check on product details, brand voice, or a promotional claim. That split is important if you do not want automation to become a liability.

Why the SEO layer is not optional

Most generic AI blog tools fail in the same way: they can write paragraphs, but they do not help the post fit the store. For me, the useful part is the structure around the copy.

I want:

A clear topic tied to a real customer problem.
Product or collection mentions that feel natural.
Internal links that help shoppers move deeper into the store.
Headings that make the post easy to scan.
A draft that can be published now or saved for later.

That is also why I keep the review checklist close. In How to Automate a Shopify Blog With Product Review and SEO Checks, I pulled the same idea into a more explicit validation flow: draft first, verify the claims, and only then push it live. I do not need perfection from the generator. I need a predictable way to catch mistakes before customers see them.

How I handle images

I used to treat article images as an afterthought. That usually meant a random stock image, a weak screenshot, or no visual at all. For ecommerce, that is a mistake. The images should support the article the same way the headings do.

With Supra Blog Automation, I can generate AI visuals that match the post instead of forcing a generic stock look. For this article, I wanted the visuals to feel like a developer workflow with strong contrast, neon accents, and clear process cues. That fits DEV style well, and it fits the subject better than a bland office photo ever would.

My rule is simple:

The banner should work as a thumbnail.
Inline images should explain the workflow.
The visuals should make the article easier to scan, not harder.

That matters even more when the post is trying to promote a product without sounding pushy. Product-aware blogging works best when the images and the copy point in the same direction: here is the problem, here is the workflow, here is the thing that helps.

What I still do manually

Automation is useful only if it leaves room for judgment. I still review:

Product names and feature claims.
Any pricing or plan reference.
Links that point to the store or to a supporting article.
Tone, especially if the post is meant to be informative instead of salesy.
The final CTA.

I also decide when a post should not auto-publish. If the article is tied to a launch, a policy change, or a detail I have not verified yet, I keep it as a draft. That is not a failure of automation. That is the point.

The upside is that once the system is set up, I can keep the blog active without having to invent a new process each time. The app is good at the repetitive parts: topics, structure, visuals, SEO scaffolding, and publishing control. I am still responsible for judgment, which is exactly how I want it.

If you want to try the same setup, the Supra Blog Automation landing page has the product overview, and the Shopify App Store listing is the fastest way to install it. The free plan is enough to test the workflow with a real draft before you commit to a larger content calendar.

TL;DR

I wanted Shopify blog automation that made me faster without making me careless. The setup that works for me is: generate a draft from real product context, add SEO and visuals, then review before publishing. That gives me the speed of automation and the safety of a human check.

If you have built your own content workflow, what part do you still refuse to auto-publish?

How I Turn a Plain Product Shot Into Shopify Ads and Try-Ons

Yassine — Mon, 06 Jul 2026 11:37:44 +0000

I was trying to turn one flat product shot into something I could use three ways: on a Shopify product page, in an ad, and in a lifestyle post. Instead of exporting one file and hoping it looked good everywhere, I wanted a repeatable visual system.

Supra AI Photo Studio is the app I used for that. It sits inside Shopify and handles the parts I usually lose time to manually: background removal, upscaling, auto enhancement, object placement, model try-ons, and short AI videos. The useful part is not that it makes pretty images. It’s that it gives me a way to keep the same product recognizable while changing the scene around it.

What I needed from one product photo

I started with one rule: the source photo had to survive being reused. If the original image is soft, awkwardly lit, or cut off, every downstream version inherits the problem.

So my checklist was simple:

Clean the base image first.
Keep the product shape accurate.
Generate outputs for specific channels, not generic “nice images.”
Make the final set feel like one brand, not four random experiments.

That sounds obvious, but it’s where most AI image workflows go sideways. People jump straight to the final scene and skip the foundation.

Step 1: Fix the source before I create anything else

The first pass was background removal and enhancement. I wanted the product isolated, sharp, and ready to reuse.

That matters because every later tool depends on the original being readable. If I’m placing a product on a model, in a boutique, or on a desk, I don’t want the AI guessing at the edges or inventing details I need to trust. I want the bottle, bag, or headphones to stay the same while the lighting, backdrop, and context change.

In practice, the order I used was:

Remove the background.
Upscale the image.
Fix color and lighting.
Only then generate the new scene.

That sequence feels slower than “generate first, refine later,” but it saves me from unusable outputs.

The editor view is what made the workflow click for me. I could see the source image, the controls, and the downstream result without leaving the app, which made it much easier to treat the edits as one system instead of a chain of disconnected tools.

Step 2: Match the image to the channel

Once the source looked clean, I stopped asking for one “perfect” image and started asking for the right image for the job.

A product page wants clarity. A paid ad wants attention. A social post wants motion and atmosphere. Those are different outputs, so the prompts should be different too.

For example:

On a product page, I want a clean studio version that makes the item easy to inspect.
For an ad, I want something that feels like it already belongs in someone’s life.
For a fashion item, I want try-on output that shows fit and context.
For content marketing, I want a b-roll or UGC-style frame that feels native to social.

That’s the part I like about Supra AI Photo Studio. It doesn’t force me into one workflow. It gives me the tools to make separate assets from the same starting point.

Step 3: Keep the variations consistent

The trap with AI-generated product visuals is ending up with a pile of images that all look good individually and fail as a set.

I’ve done that before. One scene looks premium. Another looks too warm. A third changes the product shape just enough that it feels off. The result is more content, but less trust.

What I’m trying to preserve now is consistency:

Same product proportions.
Same color story.
Same level of polish.
Same visual language across product page, ad, and social.

That’s why I think of this as a visual system, not a one-off image generator. When the outputs stay coherent, the store looks more deliberate, even if the assets came from a quick AI workflow.

Step 4: Use the app for more than still images

The feature set matters here because stills are only part of the job.

Supra AI Photo Studio also handles:

AI model try-ons for apparel, jewelry, and accessories
Object placement in environments like studios, luxury boutiques, or outdoors
UGC-style videos for marketing
B-roll videos for ads
Mockup embedding for products and packaging

That means I can start with a simple product photo and end with a small content pack instead of one isolated asset. For a Shopify store, that’s usually the real win: fewer scattered tools, less manual editing, and a more coherent catalog.

What I stopped doing

The biggest improvement wasn’t visual. It was operational.

I stopped:

Treating the original product photo as disposable.
Making the scene before cleaning the source.
Using one style for every channel.
Shipping images that looked nice but didn’t feel like the same brand.

That’s also why I now prefer to keep a written workflow alongside the image generation. If you want the narrower version of this process, I wrote about turning plain Shopify product photos into lifestyle shots. If you want the bigger picture, the broader one-photo visual kit walkthrough shows how I extend the same idea into listings, lifestyle images, and clips.

When I’d use this workflow

I’d reach for this whenever I have:

A decent product photo that needs more context.
A launch that needs more than one asset.
A catalog that feels visually uneven.
A product that needs both trust and attention.

It’s especially useful if you don’t have design time for every variation. The point is not to replace judgment. The point is to get to usable creative faster, with fewer dead ends.

If you want to try it, the app is here: Supra AI Photo Studio. The landing page also has the demo and feature overview at supra-ai-photo-studio.sktch.io.

TL;DR

Start with a clean source image.
Generate outputs for specific channels, not generic scenes.
Keep the product visually consistent across every variation.
Use the same workflow to produce stills, try-ons, and short videos.

I’m curious: if you had one good product photo today, would you use it first for a product page, an ad, or social?

How I Keep Video Preview, Editing, and Export in Sync With VideoJSON

Yassine — Sat, 20 Jun 2026 14:34:45 +0000

I kept running into the same bug in video projects: the preview looked right, the editor looked right, and the export was slightly off. By the time I had a browser renderer, a server renderer, and an editing UI, I was maintaining three versions of the same logic.

The fix was to stop treating preview, editing, and rendering as separate artifacts. I moved to one VideoJSON source of truth and let different renderers consume it. That is the workflow I now reach for when I want structured, repeatable video output instead of a one-off timeline I have to babysit.

Why Video Workflows Drift

Video drift usually shows up in one of three places:

The preview uses a different scene definition than the export.
The editor stores state in a format that does not map cleanly to rendering.
The server render has its own assumptions about sizing, fonts, or timing.

Once those paths split, small changes become expensive. A title changes in the editor, but the preview still shows an old layout. A thumbnail looks fine in the browser, but the server output crops it differently. The longer the project lives, the more you end up comparing versions instead of shipping new video.

The Pattern That Fixed It

VideoFlow's core idea is simple: describe the video in TypeScript, compile it into portable VideoJSON, and reuse that same structure across environments. The package docs call out browser rendering, server rendering, and a live DOM preview, which is exactly the separation I wanted. One model, multiple outputs.

Here is the smallest version of that workflow from the docs:

import VideoFlow from '@videoflow/core';

const $ = new VideoFlow({
  name: 'Launch teaser',
  width: 1920,
  height: 1080,
  fps: 30,
});

$.addText(
  { text: 'Hello, VideoFlow!', fontSize: 7, fontWeight: 800 },
  { transitionIn: { transition: 'overshootPop', duration: '500ms' } }
);

const videoJSON = await $.compile();

That videoJSON object is the important part. Once I have it, I can render it in the browser, hand it to a server renderer, or mount it in a live editor without rewriting the scene logic. The renderer becomes an implementation detail, not the place where the creative decisions live.

How I Split The Workflow

For me, the cleanest split looks like this:

Author the scene in TypeScript so the structure is explicit and reviewable.
Compile to VideoJSON so the scene is data, not a one-off render artifact.
Use @videoflow/renderer-browser for low-friction preview and browser-side export.
Use @videoflow/renderer-server when I need batch jobs, queues, or API-driven renders.
Use @videoflow/react-video-editor when the product needs an actual editing UI.

That approach also makes it easier to hand work between systems without translating the scene every time. If you want the browser/server handoff angle specifically, I went deeper on that in How I Built a Browser-to-Server Video Workflow With VideoFlow.

Why The JSON Layer Helps Maintenance

The biggest win is not just portability. It is maintenance.

When the scene is JSON-shaped, I can diff it, store it, generate it, and review it without opening a timeline app. That matters when content is produced by code, when an agent generates the initial structure, or when multiple team members need to reason about the same video without stepping on each other.

It is also the reason I like the template angle so much. Once the format becomes the product boundary, the workflow becomes easier to automate. I wrote more about that in How to Build a Video Template System Around a Single JSON Source of Truth, because the maintenance story is really the whole point.

Where This Pattern Is A Better Fit

I would use this approach when the work is structured and repeatable:

product demos
social clips
onboarding videos
reports and dashboards
template-driven marketing assets
app-embedded editing workflows

I would be more cautious when the job is highly bespoke motion design, because a traditional timeline editor is still better for exploratory creative work. VideoFlow is strongest when you want repeatable composition, not when you want to manually nudge every frame.

If You Want To Try It

VideoFlow is open source, and the docs are the fastest place to test the idea in practice: https://videoflow.dev/docs and https://videoflow.dev/playground. If you are building a video tool, I would start with one scene in TypeScript, compile it to VideoJSON, and see how far you can push that single model before introducing any duplication.

The short version: keep one source of truth, and let the renderers adapt to it instead of the other way around.

TL;DR: one VideoJSON document, multiple renderers, fewer mismatches.

What are you using as the source of truth for video today?

I Built a Shopify AI Assistant for Inventory and Support Alerts

Yassine — Fri, 19 Jun 2026 06:37:28 +0000

I got tired of opening Shopify every morning just to answer the same questions: did anything oversell, what needs restocking, and what support issue is waiting to turn into a customer email.

I had already explored the broader pattern in How I Built a Guardrailed Shopify AI Agent for Daily Ops. This post is the narrower version: one assistant, fewer permissions, and a very specific job. I wanted something closer to an OpenClaw for Shopify than a general-purpose chatbot, so I used Clawly to build a Shopify AI assistant that could watch inventory, draft support replies, and surface the stuff I actually need to review.

What I let it do

The biggest mistake I made early on was treating "AI assistant" as if it should just do everything. That is the fast way to get a store automation that is either useless or dangerous.

What I trust it with is much narrower:

Read product and inventory data
Pull together a daily summary
Flag low-stock items
Draft support replies
Send alerts when something looks off
Move data between Shopify and tools like Sheets, Slack, or email

What I do not let it do by default is open-ended edits. If an action can change pricing, product data, or customer-facing messages in a way I would regret at 8 a.m., it stays behind a guardrail until I explicitly allow it.

That permission layer is the whole point for me. Clawly is useful because I can scope the assistant to the store tasks I want automated without giving it blanket access to everything in Shopify admin.

The setup that actually works

The best automation I built was not a giant "run my store" agent. It was a small chain of actions that starts with the store and ends with a notification I can trust.

In practice, the flow looks like this:

Watch products, orders, or support signals.
Summarize what changed since the last check.
Write the useful part into a report or sheet.
Notify me only when something crosses a threshold.
Keep a human in the loop for anything customer-facing or irreversible.

That is also why I like this as an OpenClaw for Shopify style setup. It behaves more like a work assistant with scoped tools than a chatbot that talks confidently about your business.

The report I want every morning

I use one assistant to answer three questions before I start the day:

Did inventory dip below a level I care about?
Did orders spike or look unusual?
Did support need attention overnight?

The report does not need to be fancy. It just needs to be short, predictable, and good at escalation.

For me, that means the assistant should:

Highlight low-stock items before they become a problem
Call out sales spikes or strange order patterns
Draft a support summary instead of trying to "solve" support automatically
Make it obvious when I should step in

That combination is useful because it saves attention, not just time. A lot of automation tools can send more notifications. The real win is sending fewer, better ones.

What I still keep manual

I still keep a few things human-only:

Pricing changes
Discount logic
Customer-facing replies that sound sensitive or nuanced
Any store action I would want to audit later

That is the trade-off I actually want. I am not trying to replace the merchant. I am trying to remove the repetitive checking that keeps interrupting the merchant.

If you want the reporting-first version of this setup, I also wrote about the narrower daily-report flow in How to Set Up a Guardrailed Shopify AI Assistant for Daily Reports and Alerts.

Why I think this matters

Most teams do not need a more powerful chatbot. They need a safer assistant that knows which Shopify actions it can take, which ones it can only draft, and which ones it should never touch.

That is the value I get from Clawly. It lets me build a Shopify AI assistant around real store work: inventory checks, product cleanup, support drafts, and lightweight automation, without handing over the keys.

If you want to try the same pattern, start with one narrow assistant and one narrow job. The best first version is usually daily reports or low-inventory alerts, not full autonomy.

You can try it on the Clawly landing page or the Shopify App Store listing.

TL;DR: start with reads, drafts, and alerts, then add writes only where you can tolerate mistakes. What would you let a Shopify AI assistant handle first?

How I Built Native-Looking Shopify Swatches Without Theme Code

Yassine — Thu, 18 Jun 2026 06:33:30 +0000

I was trying to make a Shopify swatch experience feel like part of the store, not a bolt-on.

That sounds simple until you try to cover variant colors, linked products, collection pages, multilingual stores, and brand styling at the same time. The first version I hacked together looked acceptable on one product page, then got awkward everywhere else.

Supra Swatch Colors is the first setup I found that let me keep the store clean without touching theme code. It handles color and image swatches, works on product and collection pages, supports linked products and variants, and loads instantly across all Shopify themes.

The Problem I Was Solving

I did not want a swatch system that only looked good in the demo. I wanted something I could actually leave in production without becoming the person who has to babysit CSS every time merchandising changes.

That gave me a short list:

Swatches for built-in variants when the product already has color choices.
Swatches that link separate product pages when the catalog is split across listings.
Swatches on collection pages so discovery does not stop at the product page.
A setup that works with the theme I already have.
Enough styling control that the swatches do not look generic.

That last part is where most solutions fall apart. If the control surface is weak, you end up with a feature that technically works but still feels off-brand.

I had already written about why I wanted a swatch app that feels native in How I Choose a Shopify Swatch App That Feels Native. This post is the implementation version: what I actually wanted once I started using one.

Variant Swatches vs Linked Products

This is the first decision I would make again.

If the different colors are just variants of one product, I would use the built-in variant swatches. That keeps the catalog tidy and avoids creating duplicate pages that do not need to exist.

If the colorways are truly separate product pages, I would link them with swatches instead. That is a better fit when each page has its own description, imagery, or merchandising setup.

That distinction matters because it changes how the store behaves for both customers and the team editing it. If you force everything into one model, you end up fighting the content structure instead of making it clearer.

Supra Swatch Colors supports both patterns, so I did not have to pick one workflow and then patch around the edge cases later.

Why Collection Pages Matter

The best swatch system is not just a product-page detail. Collection pages are where people compare, scan, and narrow down options quickly.

If the swatches only show up after a click-through, you are making shoppers do extra work for something they should understand at a glance.

Once I saw swatches on collection cards, the store felt more coherent. The same color language followed the shopper through browse, compare, and decide.

That is also where the app’s instant-loading behavior matters. Slow swatches are worse than no swatches, because they make the page feel broken right when the customer is trying to choose.

Styling It So It Feels Native

I am picky about this part because it is easy to ship a feature that works and still looks out of place.

Supra Swatch Colors gives you more than a binary on/off switch. You can tune the swatch size, shape, tooltip, label, font, and overall style, and there are 20+ styles to work from. You can also auto-detect colors in the store or use product images to speed up setup.

That is the difference between "added swatches" and "the store has a visual system." When the controls are broad enough, you can make the component disappear into the design instead of shouting over it.

I leaned on the same no-code instinct I talked about in How I Added Shopify Color Swatches Without Touching Theme Code. If I can avoid theme edits and still get a cleaner storefront, that is usually the right trade.

The Setup I Would Recommend

If I were setting this up again, I would do it in this order:

Decide which products should use variants and which should use linked-product swatches.
Turn on swatches for the product page first so the core flow is correct.
Add collection-page swatches once the product-page behavior feels right.
Pick a visual style that matches the rest of the theme instead of starting from the loudest preset.
Test the setup on a real product family, not a perfect demo product.

That last step is where the rough edges show up. Real catalogs have odd naming, inconsistent imagery, and exceptions that never appear in a clean sandbox.

If you want the exact walkthrough, the getting started video is here: Supra Swatch Colors — Getting Started — Tutorial.

What I Liked Most

The thing I care about most is that the swatches do not feel like a separate feature layer.

The app works on all themes, supports multilingual shops, handles product and collection pages, and gives me a way to manage a lot of swatches without turning setup into a maintenance project. That is the difference between a nice screenshot and something I can leave alone after launch.

If you want to test it, the cleanest place to start is the Shopify App Store listing for Supra Swatch Colors. The product site is also useful if you want to see the positioning and examples first: supra-swatch-colors.sktch.io.

TL;DR

If your swatches still depend on theme code or feel bolted on, I would try a swatch app that supports both variants and linked products, works on collection pages, and gives you real styling control.

That is the setup that finally made my Shopify swatches feel native instead of patched together.

If you have built swatches another way, I want to know what broke first: variant mapping, collection pages, or the styling layer?

How I Turned Plain Shopify Product Photos Into a Full Launch Kit

Yassine — Wed, 03 Jun 2026 06:37:59 +0000

I used to treat product photography like a single deliverable: get one decent hero shot, ship it, move on. That works until you need the rest of the launch kit. Then you still need a lifestyle image, an on-model image, a version that looks good in a collection grid, and something that can actually stand up in paid social.

That is the problem I was trying to solve with Supra AI Photo Studio: take one plain product photo and turn it into a set of visuals I can reuse across the product page, ads, email, and social without opening a separate design queue for each one.

I am not trying to make every image look like a fake ad. I am trying to keep the product real, keep the brand consistent, and keep the workflow short enough that I will actually use it.

What I wanted out of the workflow

Before I touched the app, I wrote down the outputs I actually needed:

one cleaned-up catalog image
one lifestyle scene that adds context
one on-model version when the product needs a body
one short motion asset for ads or reels

If the workflow cannot produce those four things from the same source image, it is probably too much process for a small shop.

Start With The Clean Source

The biggest mistake I kept making was jumping straight to the fun scene. If the source image is muddy, the final output usually looks muddy too.

So I start by cleaning the image first: background removal, upscaling, and basic enhancement before I ask the app to place the product into a new environment.

The editor matters because it keeps the work in one place. I can move from the source image to the edit tools, review the canvas, and jump between variants without exporting and re-importing the same file over and over.

If you want the bigger operational picture behind this, I also wrote about how I turn one product photo into listings, lifestyle shots, and ads and how I keep Shopify product photos consistent across my catalog. Those two posts are basically the guardrails around this one.

Build The Scene, Not Just The Photo

Once the base image is clean, I use object placement to build a scene that answers a buyer question.

If the product is headphones, I want to know what it looks like on a desk, in a room, or in a premium gift context. If it is skincare, I want to know whether it reads as clinical, luxury, or everyday. The point is not decoration. The point is helping the shopper imagine the product in use.

This is the output I keep coming back to for PDPs and collections. It is polished enough to feel deliberate, but it still looks like the same product.

Use Try-On Only When The Category Needs A Body

For fashion, accessories, and some beauty-adjacent products, the product image alone is not enough. The shopper wants fit, shape, and proportion.

That is where try-on starts to earn its place. I do not use it to invent a new product story. I use it to answer the question the flat image cannot answer.

The value here is consistency. Instead of staging a new shoot every time I need a different pose or model setup, I can keep the same product and change the context around it. That makes it much easier to test what actually converts.

Make Motion Assets Too

Still images are useful, but a launch kit feels incomplete without motion.

Short product b-roll gives me a way to make a paid social ad, a social teaser, or a product announcement without turning the whole thing into a video production project.

This is the kind of asset I want when I need movement, detail, and a little more attention on a feed. It is also the easiest place to overdo it, so I keep the effect restrained and make sure the product stays readable.

What I Would Keep, And What I Would Skip

If I were setting this up for a real store, I would keep the workflow tight:

start with the cleanest source image you have
generate one catalog-safe version first
create one lifestyle scene that matches the brand
add one on-model or context-heavy version only if it helps the buyer
generate one motion asset if you need ads or social content

And I would skip anything that makes the product feel less trustworthy:

scenes that are too stylized for the price point
lighting that changes the product color
models or settings that drift away from the brand
too many variants before you know which one is the winner

That last point matters. More images are not automatically better. Better images are better.

Why I Kept This In My Stack

The reason I kept testing Supra AI Photo Studio is simple: it reduces the number of tools I need to finish one launch.

The app listing is here if you want the short version: Supra AI Photo Studio on Shopify. The landing page has the longer feature breakdown and examples: supra-ai-photo-studio.sktch.io. If you want to see the product in motion first, the demo trailer is the fastest way to get the shape of it.

There is a free plan, which makes it easier to test the workflow on one SKU before you commit to a larger batch.

Final Take

I would not use AI photo tools to replace a good source image. I would use them to make that source image earn more places in the launch.

If you are sitting on a folder of plain product shots, pick one SKU and build four outputs from it: one clean catalog image, one lifestyle scene, one contextual or on-model image, and one motion asset. If that set is good enough to ship, the workflow is doing its job.

How I Built a Shopify UGC Video Variation Pipeline

Yassine — Sat, 30 May 2026 14:37:03 +0000

I was trying to get more UGC-style creative out the door without turning every variation into a new shoot. The problem was not ideas. It was throughput.

Supra UGC Maker gave me a way to treat video like a repeatable workflow instead of a one-off deliverable. I can pick an avatar or generate a custom AI model, set a scene, add the Shopify product, write the script, choose the voice and tone, then generate segments I can reuse later.

That matters because the fastest way to waste time on ecommerce video is to build from scratch every time. I wanted a system where the variables were explicit, so I could test hooks, scenes, and calls to action without rebuilding the whole asset.

I also borrowed the brief-first approach I used in How to Turn a Shopify Product Page Into a UGC Video Brief and extended it into the variation stage. The goal was not “make a video.” The goal was “make a video system.”

The workflow I actually wanted

If I strip the process down, the useful inputs are simple:

{
  "avatar": "preset or custom AI model",
  "scene": "studio, outdoor, boutique, or brand-specific",
  "product": "Shopify product",
  "script": "what the avatar says",
  "voice": "tone and delivery",
  "output": "short-form UGC-style segments"
}

The value is in the separation. Avatar, scene, product, and script are independent knobs. When one of them changes, I can tell whether the change affected the result.

That is why I care about previewing scenes before generating, and why I like that I can reorder, trim, update, and regenerate clips inside one project. If a hook is weak, I can replace the hook without throwing away the rest of the setup.

The matrix is the product

The biggest mistake I made early was treating one video as if it represented the whole idea. It does not.

What I need is a matrix:

One product.
Several hooks.
A few avatar choices.
A few scenes.
Different tones.
Different calls to action.

I used the same thinking I wrote about in How to Create Shopify UGC Video Ad Variations From One Brief and pushed it one step further. Instead of asking, “What is the best video?”, I ask, “What is the smallest set of changes that gives me signal?”

That keeps the process honest. If the only thing I change is the hook, I can compare hooks. If I also change the avatar, the scene, and the script, I have no idea what actually worked.

For a Shopify store, that matters because the same creative usually has to do more than one job. It might need to sell in a paid social ad, explain the product on a product page, and keep working in email later.

Reusable projects beat one-off assets

The feature I would miss most if I switched tools is the ability to save reusable scenes and projects. That sounds minor until you start running the same product through multiple campaign angles.

Reusable projects let me keep:

a consistent brand look,
a known-good avatar,
a working scene setup,
a script style that already performs,
and a library of variations I can come back to.

That is the real workflow win. I am not trying to generate one perfect ad. I am trying to build a library of usable assets that do not need a full production cycle every time I want a new angle.

I also like that the output is not trapped in one channel. Once the segment exists, I can use it in ads, product pages, launch pages, email campaigns, seasonal promos, or post-purchase education. The same asset can do different work depending on where I place it.

Where I would ship the clips first

My first pass would be:

a short ad version for paid social,
a product page version that explains the item,
a teaser for email,
and one follow-up version for post-purchase education.

That mix gives me a better read on what the creative is actually doing. If the ad version pulls attention but the product page version does not clarify the offer, I know the script needs work, not the whole concept.

It also helps that Supra UGC Maker is positioned around Shopify merchants who need more short-form product video content without hiring influencers, videographers, or editors for every variation. That is the core constraint I was solving.

What I would tell another developer

If you are building your own ecommerce creative workflow, do not start with the final polished video. Start with the variables:

avatar
scene
product
script
voice
CTA

Then make it easy to regenerate just one part of the asset at a time.

That is the difference between a tool that helps you make one video and a tool that helps you test creative systematically.

If you want to try the same workflow, the product is on the Supra UGC Maker landing page and the Shopify App Store.

TL;DR: I stopped thinking about UGC as a one-off asset and started treating it like a repeatable pipeline. Once the inputs are explicit, the creative gets easier to test and much easier to reuse.

What would you test first: hook, scene, or avatar?

How I Built a Programmatic Video Generator With VideoFlow in Node.js

Yassine — Fri, 22 May 2026 10:38:14 +0000

How I Built a Programmatic Video Generator With VideoFlow in Node.js

I kept running into the same problem: once a video lived in a manual timeline, I lost the ability to regenerate it cleanly. One tiny copy change, one updated product frame, or one new render target and the whole thing turned into another editing job.

VideoFlow pushed me toward a better shape: describe the video in TypeScript, compile it into portable VideoJSON, and render the same source in the browser, on a server, or inside a live preview. That makes the pipeline feel like code instead of a one-off creative file.

If you want the short version, here is the workflow I actually care about:

Start with @videoflow/core and model the video in code.
Keep the intermediate format portable so it can be stored, versioned, and reused.
Pick the renderer based on where export needs to happen.
Add the React editor only when users need a visual layer on top.

The project is open source under Apache-2.0, and the main entry points are the VideoFlow site, docs, core docs, renderers docs, React video editor, playground, and examples.

The Small Pipeline I Actually Wanted

I did not want a fancy editorial toolchain. I wanted a small, repeatable path from structured input to MP4 output. In practice, that means the video authoring step needs to be code-first, and the rendering step needs to stay flexible.

This is the minimal shape I kept coming back to:

npm install @videoflow/core

import VideoFlow from "@videoflow/core";

const $ = new VideoFlow({
  name: "My Video",
  width: 1920,
  height: 1080,
  fps: 30,
});

$.addText(
  { text: "Hello, VideoFlow!", fontSize: 7, fontWeight: 800 },
  { transitionIn: { transition: "overshootPop", duration: "500ms" } }
);

const json = await $.compile();
const blob = await $.renderVideo();

That tiny example is doing the important part: it separates scene authoring from output. compile() gives you a portable representation of the video, and renderVideo() gives you the MP4 when you need it.

I like this setup because it turns video into a thing I can inspect, rebuild, and swap between environments without rewriting the whole project. For product demos, templated social clips, onboarding videos, or generated reports, that matters more than any single animation trick.

Why VideoJSON Changes The Maintenance Story

The big win is not just that the videos are generated. It is that the source of truth becomes portable.

When the intermediate format is JSON, I can:

Store templates in Git and review changes like code.
Feed structured data from a CMS, database, or AI agent into the same template.
Reuse one video design across multiple render targets without rebuilding the scene logic.
Keep the project easier to diff when a prompt, scene, or CTA changes.

That is also where the comparison to older workflows becomes clearer. Traditional timeline editing is great when the work is mostly manual and creative. But if the goal is repeatability, versioning, or automation, a JSON source of truth is much easier to reason about.

If you want the browser-export angle, I covered that separately in How to Build a Browser-Based MP4 Export Pipeline with VideoFlow. For the portable-data angle, How to Build a Portable JSON-to-Video Workflow with VideoFlow goes deeper on the same idea.

Browser, Server, And Live Preview

VideoFlow is useful to me because the same video description can move through different render paths instead of being trapped in one environment.

@videoflow/renderer-browser is the right fit when export should happen in the user's browser.
@videoflow/renderer-server is the better fit when I want queue jobs, APIs, CI, or batch rendering.
@videoflow/renderer-dom is what I want when I need a live preview inside an app or editor.

That separation matters because it lets the same scene logic serve multiple product needs. An editor can preview frames live. A backend can render jobs overnight. A browser app can export without shipping the whole project to a rendering service. I wrote about the server/browser split before in How to Build a Video JSON Pipeline That Renders Everywhere With VideoFlow.

Where The React Editor Fits

I do not reach for the React editor first. I reach for it when the product needs non-developers to adjust or inspect the video without touching code.

The React video editor is the layer that makes that practical: multi-track timeline, drag and drop, keyframes, transitions, undo/redo, uploads, theme choices, and MP4 export.

That is the difference between a library and a workflow. The library gives me the rendering primitive. The editor gives me a human interface when the product calls for one.

What I Still Review Manually

Automation is not the same thing as blind publishing. I still review the things that can break trust fast:

Product names, prices, and claims.
Copy that is too generic or too promotional.
Visuals that do not match the intent of the post.
Templates that should be versioned before they are reused.

For that reason, I like treating VideoFlow as the engine and not the entire editorial process. The engine should be fast, portable, and predictable. The review step should stay human where accuracy matters.

I also keep How I Kept Video Templates Versionable in Git With VideoFlow and How I Built a Programmatic Video Generator in Node.js nearby when I am deciding whether to ship a scene as code or as a visual editor workflow.

Next Step

If you are starting from scratch, I would do it in this order: create one template, render it once in Node, then decide whether browser export or a React editor is the next requirement. The fastest way to test that path is the VideoFlow playground plus the docs.

What would you automate first?

How To Generate Long Form AI Videos In N8N Workflows

Yassine — Mon, 04 May 2026 21:54:30 +0000

If you’ve dreamed of turning a single prompt into a polished, long-form video—automatically—this guide will show you how to do it inside n8n using Scrptly. Scrptly is an AI Video Agent that turns your prompts into ads, product showcases, anime, or short films. With its native n8n integration, you can automate entire video pipelines for ecommerce, faceless YouTube channels, educational explainers, mini-docs, and more.

What you’ll learn in this guide:

How to install and authenticate the Scrptly n8n node
How to design a robust workflow for long-form AI video generation
Proven prompt templates and best practices for character and scene consistency
Tips for scaling, error handling, and downstream publishing

Learn more or get started: https://scrptly.com/

Why Scrptly + n8n for long-form AI video automation

Scrptly’s swarm of specialized AI sub-agents—research, screenplay, character design, narration, and editing—work together to produce cohesive videos from a single prompt plus optional context images. This is especially powerful for longer content, where character and environment consistency are crucial.

Key advantages:

Long-form reliability: Excellent character and environment consistency across scenes.
One-prompt simplicity: Provide a detailed prompt and optional context images—Scrptly handles the rest.
Automation ready: Native n8n node, plus an API and MCP server for agent-to-agent orchestration.
Scalable: Use the n8n node in scheduled, webhook-triggered, or data-driven workflows.

Start here: https://scrptly.com/

Prerequisites

An n8n instance (self-hosted or cloud)
A Scrptly account and API key from your account page: https://scrptly.com/

Optional but helpful:

Product images or brand assets to use as context images for consistency
A content calendar source (Google Sheet, CMS, database) to feed topics, scripts, or metadata

Step 1: Install the Scrptly n8n node

1) In n8n, go to Settings > Community Nodes > Install New
2) Search for: n8n-nodes-scrptly
3) Click Install

Source and docs: https://github.com/ybouane/n8n-nodes-scrptly

Step 2: Add credentials

1) In the n8n editor, open the Credentials tab
2) Create New Credential > Scrptly API
3) Paste your Scrptly API key and Save

Step 3: Blueprint for a long-form video workflow

Here’s a robust pattern you can adapt for ecommerce, documentaries, or faceless channels:

Trigger (Schedule or Webhook)
Data Prep (HTTP Request or Google Sheets): Fetch topic, product details, or research notes
Transform (Set or Function): Build a structured prompt and gather context image URLs
Scrptly (Generate Video): Provide prompt, context images, and budget
Wait/Async Handling: Either wait for completion or poll task status (if configured)
Post-Process: Upload to storage, send to a CMS, or publish to social platforms
Notify/Log: Send a Slack/Email notification and persist the video URL and metadata

Step 4: Configure the Scrptly node

In your workflow, add the Scrptly node and set these fields:

Prompt: A thorough description of your video—story arc, style, length, aspect ratio, key scenes, tone, and CTA.
Context Images (optional): Brand/product images, character references, or environment stills to ensure consistency.
Approve Up To: Maximum token budget (default 10,000) to control complexity/cost.
Wait For Completion: On to block until the video is ready; off to return immediately with a task ID for polling.

Tip: For long-form content, lean on context images to lock character and environment consistency. This is where Scrptly shines.

Prompt templates for long-form videos

Use these as starting points and adapt per niche.

1) Ecommerce documentary-style product story (3–6 minutes)
"Create a cinematic mini-documentary about the journey from raw material to finished product. Focus on tactile close-ups, macro textures, and transitions from workshop ambiance to studio showcase. Introduce a recurring artisan character who appears across scenes. Maintain a warm, natural color grade, steady camera, soft ambient sound design, and a calm voiceover. Integrate product close-ups based on provided context images. End with a clear CTA to learn more. Format: 16:9, YouTube-ready."

2) Faceless YouTube explainer (5–10 minutes)
"Produce a structured explainer with a hook, three chapters, and a summary. Keep on-screen text minimal and rely on smooth cutaways and simple motion graphics. Maintain consistent visual motifs and recurring background environment. Include a friendly but authoritative narration. Insert subtle section bumpers every 90 seconds. Close with a concise takeaway and CTA. Format: 16:9."

3) Brand UGC hybrid ad (60–120 seconds)
"Make a UGC-style ad featuring hands-on product interactions, natural lighting, and lifestyle b-roll. Keep character appearances consistent using context images. Alternate between handheld and locked-off shots. Include overlays that call out 3 benefits and one social proof element. End with a bold CTA and logo reveal from context images. Format: 9:16 for short-form platforms."

Example: Building the prompt dynamically in n8n

Use a Set or Function node to assemble your prompt from upstream data.

{
  "title": "How to Sleep Better in 7 Days",
  "chapters": [
    "Evening light and caffeine timing",
    "Bedroom temperature and sound",
    "Pre-sleep routines and journaling"
  ],
  "style": "calming, cinematic, soft piano score, minimal text on screen",
  "cta": "Subscribe for weekly science-backed habits"
}

Then merge into a final prompt string:

Create a 6–8 minute faceless explainer titled: {{title}}.
Use three chapters: {{chapters}}. Keep shots cohesive with recurring bedroom and desk environments. Maintain character and room consistency with the provided context images. Apply a calming, cinematic grade, soft piano score, clean lower thirds, and natural voiceover pacing. End with CTA: {{cta}}. Output 16:9, YouTube-ready.

Pass this final string to the Scrptly node’s Prompt field, and add context image URLs from your product or brand library.

Handling async generation

Recommended: Keep "Wait For Completion" on during prototyping.
For high throughput: Turn it off, capture the returned task ID, then poll status or continue the pipeline when the video is ready. Use a Wait or polling loop strategy in n8n and route results to upload/publish nodes.

Post-processing and publishing ideas

Store the video in cloud storage and write the URL to your CMS
Auto-generate social cutdowns by triggering additional Scrptly jobs with new prompts
Send Slack/Email notifications with thumbnail, title, and links
Schedule platform-specific posts (YouTube, Instagram, TikTok) via their connectors

Developer note: Using the Scrptly SDK

If you also want programmatic control alongside n8n, install the package and set your API key:

npm install scrptly

import Scrptly from 'scrptly';

Scrptly.setApiSettings({
  apiKey: process.env.SCRPTLY_API_KEY,
});

Explore the platform and APIs: https://scrptly.com/

Best practices for long-form consistency

Provide 2–5 high-quality context images for each recurring character or product.
Name characters and locations in your prompt to help the agent maintain identity across scenes.
Specify pacing and structure (acts, chapters, timestamps) to guide narration and editing.
Define aspect ratio early (16:9 for YouTube, 9:16 for shorts) to avoid reframing.
Use a steady voice style (calm, energetic, documentary) to match brand tone.
Budget wisely: increase the token budget for complex multi-location stories.

Troubleshooting checklist

Characters drifting between scenes? Add more specific context images and reiterate names, wardrobe, and settings.
Overly fast pacing? Ask for longer beats and fewer cuts per minute.
Visual style mismatch? Define color grade, lighting, camera movement, and lens feel in the prompt.
Running time too short/long? State a clear target duration with allowable variance.

Example workflow: Faceless channel episode, weekly

Trigger: Schedule weekly at 9 AM
Fetch topic: HTTP Request to your CMS or spreadsheet adapter
Build prompt: Function node composes chapters, tone, CTA
Scrptly node: Generate long-form 16:9 episode with context images
Upload: Cloud storage node writes the file and returns URL
Publish: YouTube node drafts title, description, and thumbnail
Notify: Slack node posts the episode link to your team

Ready to build your first automated long-form video?

With Scrptly’s AI Video Agent and n8n, you can scale a consistent, on-brand video pipeline from a single prompt. Whether you’re an ecommerce marketer, educator, researcher, or entertainment creator, this stack gives you production-grade output without manual stitching.

Start creating today: https://scrptly.com/

—

Some images in this article were generated via AI tools and the article itself was proof-read with AI.

How To Download A Framer Site As HTML And Assets

Yassine — Wed, 01 Apr 2026 12:20:25 +0000

If you’ve ever wished you could download a Framer site as static HTML, CSS, JS, and images for fast, low-cost hosting and full control, you’re in the right place. This guide walks you through a reliable, repeatable way to go from Framer to HTML using a purpose-built Framer Exporter/Framer Downloader: ExFlow.

Whether you’re optimizing performance, avoiding vendor lock-in, or finding Framer too expensive for hosting, the workflow below helps you Download a Framer Site, self-host it anywhere, and keep your interactive design intact.

Why export a Framer site to HTML and assets?

Self-host Framer site to slash recurring hosting costs and scale on your terms.
Gain flexibility to integrate with CDNs, CI/CD, or security tooling.
Improve performance and control caching at the edge.
Create secure, versioned backups of your live website.
Explore a Framer Alternative workflow when you need static builds.

What you’ll need

A published Framer site URL.
A desktop environment to unzip and preview your exported site.
Optional: credentials for your target host (FTP, S3, or Git platform).

The fastest path: Use ExFlow (Framer Exporter)
ExFlow is a streamlined Framer to HTML exporter and downloader that turns a live site into downloadable static files—including CSS, JS, images, and multi-page structures—so you can deploy anywhere.

Try ExFlow: https://exflow.site
Key features relevant to Framer users:
- Export CSS, JS, images/media
- Export all pages as .html
- Remove the “Made with” badge
- Add custom script.js and style.css
- Optional sync to Git, S3, or FTP
- Optional built-in hosting with custom domain support

Step-by-step: How to Download a Framer site as HTML and assets
1) Open ExFlow

Visit https://exflow.site.
You can start right away—no complex setup.

2) Enter your Framer site URL

Paste the full URL of your published Framer site (e.g., https://yourdomain.com).
Tip: Use the production domain you control for the most complete export.

3) Configure export settings

Export CSS files: Ensure styles are captured in separate, cacheable files.
Export JS files: Include site interactions and scripts required by your pages.
Export images/media: Pull down all media used across pages and components.
Export all pages: Capture multi-page structures, including CMS-driven content where public.
Pages as .html: Make sure each page is saved as a standalone .html file.
Remove “Made with” badge: Toggle to remove platform badges from your static build.
Add custom script.css / style.css: Inject additional logic and styling at build time.
Optional Sync:
- Git Sync: Push directly to a repo for CI/CD (e.g., GitHub Pages).
- S3 Sync: Auto-deploy to Amazon S3 for static hosting with a CDN.
- FTP Sync: Upload to your classic shared or VPS host.

Security note: When using Sync features, you’ll be asked for credentials (FTP/S3/Git). Only provide credentials for accounts you control and rotate them regularly. Treat them as sensitive information.

4) Start the export

Click to generate your static bundle. ExFlow will crawl your site, collect assets, and package everything into a neat zip.
Larger sites may take longer—keep the tab open during processing.

5) Download the zip (or auto-sync)

Download the zip to your computer, or let ExFlow push it via Git/S3/FTP if you enabled Sync.
You now have a fully portable, static version of your Framer site.

6) Verify locally

Unzip the package.
Open index.html in your browser.
Click around to ensure navigation, animations, and assets load correctly.

Where to host after exporting (3 quick options)
1) Host on ExFlow’s servers

The simplest path: Choose Hosting in ExFlow and link your custom domain.
You’ll get unlimited bandwidth, automated updates via re-exports, and a single place to manage your static site.

2) Host on Amazon S3 (with or without a CDN)

Create an S3 bucket and enable static website hosting.
Use ExFlow’s S3 Sync to push files directly.
Map your domain via Route 53 or your DNS provider; optionally add CloudFront for global caching.

3) Host via Git + static site services

Sync to a Git repository using ExFlow’s Git option.
Deploy with GitHub Pages, Netlify, or a similar static host.
Benefit from rollbacks, previews, and CI-based deployments.

Pro tips for a smooth Framer to HTML export

Clean URLs vs. .html: With static hosting, /about may become /about.html unless you configure rewrite rules. Many hosts let you keep clean URLs via redirects.
Forms and dynamic features: Native static exports don’t process server-side forms or search. Use serverless functions or third-party form handlers as needed.
Fonts and third-party embeds: Confirm licensing and embed codes still load over HTTPS from their providers.
Relative vs. absolute paths: Keep assets relative where possible for portability across environments.
Password-protected pages: Only export content you own or have rights to access. Provide passwords to ExFlow only when authorized and necessary.

Common questions (FAQs)

Will animations and interactions work after export? Most client-side animations and interactions that Framer ships as JS/CSS continue to work. Server-side or proprietary features that depend on the platform runtime may require adjustments.
Can I keep my CMS-driven pages? Publicly accessible CMS content can be captured as static HTML. Dynamic features that rely on a live backend may need client-side data fetching or a build pipeline for updates.
Is this a good Framer Alternative? Exporting gives you a static alternative for sites that don’t need live backend features—ideal when you want speed, portability, and total control.
What if Framer hosting is too expensive? Exporting and self-hosting can be significantly cheaper, especially at scale. With ExFlow, you can move from Framer to HTML and host wherever it’s most cost-effective.

Why ExFlow over generic site downloaders?

Purpose-built for modern site builders: Unlike generic crawlers (which often break animations or miss dynamic content), ExFlow handles today’s front-end stacks more reliably.
Full-asset capture: HTML, CSS, JS, images/media, and multi-page structures in one flow.
Seamless deployment: Built-in Hosting and direct Sync to Git, S3, and FTP.
Badge removal and custom injects: Ship a clean, branded site with your own scripts and styles.

Ethical and legal reminder
Only export and self-host assets for sites you own or have explicit permission to export. Review your platform’s terms of service and respect licensing for fonts, images, and third-party scripts.

Get started now

Turn your live project into a portable static site in minutes: https://exflow.site
Explore a Framer Downloader and Framer Exporter workflow that keeps your creativity intact while delivering the control and savings you need.
It’s the straightforward way to Download a Framer Site, go from Framer to HTML, and Self-host your Framer site—without compromises.

Some images in this article were generated via AI tools and the article itself was proof-read with AI.

DEV Community: Yassine

I Tested Shopify 3D Product Media Before Touching My Theme

How I Export Webflow Sites to Static HTML Without Losing CMS Content

How I Built a Review-First Shopify Blog Automation Pipeline

How I Built a Review-First Shopify Blog Automation Pipeline

The workflow I actually want

Why the SEO layer is not optional

How I handle images

What I still do manually

TL;DR

How I Turn a Plain Product Shot Into Shopify Ads and Try-Ons

What I needed from one product photo

Step 1: Fix the source before I create anything else

Step 2: Match the image to the channel

Step 3: Keep the variations consistent

Step 4: Use the app for more than still images

What I stopped doing

When I’d use this workflow

TL;DR

How I Keep Video Preview, Editing, and Export in Sync With VideoJSON

Why Video Workflows Drift

The Pattern That Fixed It

How I Split The Workflow

Why The JSON Layer Helps Maintenance

Where This Pattern Is A Better Fit

If You Want To Try It

I Built a Shopify AI Assistant for Inventory and Support Alerts

What I let it do

The setup that actually works

The report I want every morning

What I still keep manual

Why I think this matters

How I Built Native-Looking Shopify Swatches Without Theme Code

The Problem I Was Solving

Variant Swatches vs Linked Products

Why Collection Pages Matter

Styling It So It Feels Native

The Setup I Would Recommend

What I Liked Most

TL;DR

How I Turned Plain Shopify Product Photos Into a Full Launch Kit

What I wanted out of the workflow

Start With The Clean Source

Build The Scene, Not Just The Photo

Use Try-On Only When The Category Needs A Body

Make Motion Assets Too

What I Would Keep, And What I Would Skip

Why I Kept This In My Stack

Final Take

How I Built a Shopify UGC Video Variation Pipeline

The workflow I actually wanted

The matrix is the product

Reusable projects beat one-off assets

Where I would ship the clips first

What I would tell another developer

How I Built a Programmatic Video Generator With VideoFlow in Node.js

How I Built a Programmatic Video Generator With VideoFlow in Node.js

The Small Pipeline I Actually Wanted

Why VideoJSON Changes The Maintenance Story

Browser, Server, And Live Preview

Where The React Editor Fits

What I Still Review Manually

Related Reads

Next Step

How To Generate Long Form AI Videos In N8N Workflows

Why Scrptly + n8n for long-form AI video automation

Prerequisites

Step 1: Install the Scrptly n8n node

Step 2: Add credentials

Step 3: Blueprint for a long-form video workflow

Step 4: Configure the Scrptly node

Prompt templates for long-form videos

Example: Building the prompt dynamically in n8n

Handling async generation

Post-processing and publishing ideas

Developer note: Using the Scrptly SDK

Best practices for long-form consistency

Troubleshooting checklist

Example workflow: Faceless channel episode, weekly

Ready to build your first automated long-form video?