DEV Community: Yassine

I Added a Tiny Smoke Test After Every Static Site Export

Yassine — Sun, 13 Sep 2026 06:30:54 +0000

I used to think a successful static site export was the finish line. The files appeared, the home page opened, and I moved on. Then I would find out later that a deep link returned a 404, a font was loading from the wrong place, or the archive was only useful on the machine that created it.\n\n\n\nThe fix was not a bigger deployment system. I added a tiny smoke test after every export. It takes a few minutes, catches most of the unglamorous failures, and gives me a useful answer when someone asks whether the exported site is actually portable.\n\nI use ExFlow to export published Webflow sites into static HTML, CSS, JavaScript, fonts, and media. The export itself is useful, but the habit that made it trustworthy was treating the result as a build artifact that needed a short acceptance test.\n\n## What the home page check misses\n\nOpening index.html tells you almost nothing about paths, direct navigation, or deployment behavior. Browsers can be generous when local files are opened directly. A static host is not always so forgiving.\n\nI learned to test four things:\n\n1. The home page loads.\n2. A deep URL loads directly.\n3. The main assets load from their deployed paths.\n4. The primary navigation still reaches the expected pages.\n\n\n\nThat list is intentionally modest. I am not trying to recreate a full end-to-end test suite for an archive. I am checking whether the exported site behaves like a site rather than a folder of files.\n\n## I start a real static server\n\nThe first change was to stop testing exports by double-clicking files. I run a local static server from the exported directory instead. Any server works; the important part is accessing pages through HTTP.\n\n~~~sh\nnpx serve .\n~~~\n\nThen I open the home page and paste a deep path into the address bar. I do not navigate there from the home page first. Direct navigation is the check that reveals whether a path only works because the previous page happened to be open.\n\nFor a production-like check, I deploy the export to a temporary static host or a simple branch preview. That is where relative asset paths, redirects, and host-specific routing rules become visible.\n\n## I keep one page inventory next to the export\n\nBefore I export, I make a small text file with the pages that matter: home page, contact page, main collection or product guide pages, an important campaign page, and one deep article or resource page.\n\nIt is not a sitemap. It is a risk list. These are the pages that would create confusion if they disappeared during a redesign or handoff.\n\nI picked up this idea while creating a Webflow redesign backup checklist. The useful part is not collecting every URL. It is making sure the high-value paths have a named place in the verification step.\n\n## The curl check is boring on purpose\n\nOnce the export is on a preview URL, I use a compact status check. It does not replace looking at the page, but it makes obvious failures hard to ignore.\n\n~~~sh\nfor path in / /guides /contact; do\n curl -L -s -o /dev/null -w '%{http_code} %{url_effective}\n' https://preview.example.com$path\ndone\n~~~\n\nI expect a success response for each path. If a page returns a redirect, I want to see the final destination. If it returns a 404, I fix the path or hosting rule before I call the archive ready.\n\n\n\nI also open developer tools for one pass and look for missing assets. Fonts and images are the most common quiet failure. A page can look almost right while using a fallback font or missing the one product image that was supposed to carry the page.\n\n## I write down the live dependencies\n\nAn exported static site can preserve the public layout while some features remain connected to live services. Forms, commerce, account pages, analytics, embeds, and search integrations do not automatically become standalone just because their surrounding page exported.\n\nI keep a short README beside the export with three sections: what was tested, what is static, and what requires a service. This turns a handoff from “here is a ZIP” into something another person can understand without guessing.\n\nFor Squarespace sites, I use the same approach: make the public copy, then document the pieces that need separate handling. That is the practical core of this Squarespace storefront archive workflow.\n\n## The test I would automate next\n\nIf I had many exports to check, I would put the page inventory in a small JSON file and have a script fetch each URL, assert a success response, and flag missing image or stylesheet requests. I would still keep a visual pass for key pages, because a 200 response cannot tell me whether the wrong font has shifted every headline.\n\n\n\nBut even without automation, this little ritual has changed the quality of my exports. I now know whether a static copy is usable before a redesign makes the old site difficult to inspect.\n\n*TL;DR:* export the site, serve it over HTTP, test a few direct URLs, check the assets, and record the live dependencies. The result is not just a backup. It is a reference site you can actually hand to someone. What is the one deep link you would hate to discover is missing after a redesign?

I Replaced My Ad-Video Spreadsheet With a Tiny JSON Contract

Yassine — Fri, 11 Sep 2026 18:32:17 +0000

Liquid syntax error: 'raw' tag was never closed

I Treat Every Framer Export Like a Deployment Rehearsal

Yassine — Sun, 06 Sep 2026 17:33:01 +0000

I was preparing a Framer landing page for a launch where a broken animation or missing font would be painfully visible. The page looked great in Framer, but I did not want the first time I saw its static version to be after DNS had changed.

So I started treating the export as a deployment rehearsal: capture the published site, put the output somewhere safely separate, test the actual files, and keep a known-good rollback copy. It is not a glamorous extra step. It has saved me from finding the important problems during the least convenient hour.

For this workflow, ExFlow's Framer exporter is the practical bridge. It can collect a published Framer site's HTML, CSS, JavaScript, fonts, and media, then produce a downloadable static site or sync it to Git, S3, FTP, or ExFlow Hosting. The point is not merely getting a ZIP; it is giving the launch a versioned, testable artifact.

Why I stopped calling this an export

An export sounds final and mechanical. A rehearsal has a question behind it: would I trust this exact build if it became public right now?

Framer is excellent at making a landing page feel finished quickly. That polish can hide dependencies: font files, image paths, interaction scripts, responsive layout choices, and routes that only reveal themselves once the site lives outside the editor. A generic downloader might make a passable copy of a simple page, but it is a poor place to discover whether your animated hero, nav behavior, or mobile layout survived.

The static output is also useful before a redesign or client handoff. I used the same Git-first thinking when I put a Webflow site in Git before a high-risk launch: the version that can be inspected and rolled back is more useful than the version that merely exists in a visual editor.

My Framer staging sequence

1. Freeze the published URL I actually want to test

I begin with the published Framer URL, not a half-finished canvas view. That keeps the rehearsal honest: the exporter sees the public page structure and assets that visitors would receive. Before exporting, I make a tiny launch note with the expected routes, the key CTA destinations, and the two or three interactions that would be embarrassing to lose.

For a typical marketing site, that note includes:

the home page, pricing page, and one campaign route
desktop and narrow mobile breakpoints
the hero motion and any scroll-driven section
contact or waitlist forms
canonical tags, social preview metadata, and redirects

2. Export into a staging destination, not production

I run the Framer export in ExFlow and send the result to a separate place first: a ZIP for local inspection, a staging bucket, or a dedicated Git branch. The staging destination matters because it lets me test a real static deployment without replacing the live site.

If I am using Git, I review the file tree before I deploy. I am looking for the boring but essential things: expected pages, CSS and JavaScript bundles, image and media directories, and font files. A sudden absence is often easier to spot in a file list than in a browser tab.

3. Test the behaviors, not just the screenshots

A desktop screenshot can look perfect while the site is still wrong. My staging test has three passes.

First, I click every navigation item and CTA from a clean browser session. Internal links should stay on the staging host; intentional external links should go where I expect.

Second, I test the page at a narrow breakpoint and a normal desktop width. I pay special attention to overflow, font fallback, sticky elements, and menu behavior. Those are the spots where a polished layout can become visibly fragile.

Third, I exercise motion and interactive sections. I do not need every pixel to be identical, but I do need the effect to load, the timing to feel reasonable, and the interaction not to block the rest of the page. If an animation is essential to the message, I record a quick before-and-after screen capture instead of trusting memory.

The QA gate I use before promoting staging

This is the short checklist that prevents me from promoting a static copy just because its home page loaded once:

Every expected route returns a page, not a directory listing or fallback error.
Images, video, and fonts load without console errors.
Primary CTAs and forms have their intended destination or handling.
Mobile navigation and key sections work at the smallest supported width.
Title, description, canonical, and social-preview tags are present.
Redirects are mapped before any old host is retired.
The previous working build is still available for rollback.

The last item changes the feel of a launch. I do not need a heroic fix under pressure if I can restore the known-good static build while I diagnose the new one. That is why I also liked the idea of rehearsing an exit before it is urgent; this Squarespace exit rehearsal makes the same case from a different platform.

Where ExFlow fits—and where it does not

ExFlow handles the platform-specific capture step for Framer and gives me static files I can inspect or deploy. It is especially useful when the goal is a staging preview, a backup, a client handoff, or hosting independence—not just a one-time scrape. I still own the release work: deciding where to host the files, validating forms or third-party services, and making a rollback plan.

If your project is on another visual builder, ExFlow also has dedicated workflows for Webflow and Squarespace. I would keep the platform-specific exporter aligned to the platform in front of you, though; the risks worth testing are different for each one.

TL;DR

My Framer export workflow is simple: export the published site, stage the static files somewhere safe, test routes/assets/breakpoints/motion, then promote only after the rollback copy is ready. Try the Framer exporter on one noncritical page first and use that run to build your own QA gate.

What is the one Framer behavior you would be least comfortable discovering was missing after launch?

I Turned Shopify UGC Creative Into a Small Test Harness

Yassine — Mon, 24 Aug 2026 13:31:53 +0000

I kept making the same mistake with short-form product video: I would ask for more variations before I had defined what was actually varying. The result was a folder of clips that looked busy, not a set of useful tests.

What fixed it was treating Shopify UGC creative like a small test harness. Not a giant ad-production system—just a repeatable contract for producing, reviewing, and learning from a handful of AI avatar videos. I use Supra UGC Maker as the generator because it lets me control the avatar, scene, product reference, script, voice, and clip revisions in one project.

This is the setup I wish I had started with.

The Eight Titles I Considered

Before drafting, I explored these distinct search-intent angles:

How to Build a Shopify UGC Video Testing Workflow
I Turned Shopify UGC Creative Into a Small Test Harness
Five AI Avatar Video Variables Worth Testing for Ecommerce
A Practical Shopify UGC Video QA Checklist
How to Reuse One Product Script Across Multiple Video Ads
AI UGC Videos vs Influencer Shoots: Where Testing Helps
The Shopify Product Video Experiment I Run Before Launch
How to Ship Video Ad Variations Without Rebuilding the Brief

I picked the test-harness angle because it answers a real implementation problem: how to get comparable outputs instead of endlessly changing everything at once.

The Harness: Lock Four Things, Change One

My first version was almost embarrassingly small. Every video project gets four fields:

const creativeContract = {
  product: "hydration serum",
  audienceProblem: "skincare routine feels too complicated",
  proof: "shows the texture and a simple application step",
  cta: "See how it fits into your routine"
};

Then I choose one variable to test: the opening hook, the avatar, the scene, the voice/tone, or the call to action. The product, core problem, proof, and CTA stay stable until I have a reason to change them.

That constraint matters. If a clip has a new avatar, a different product framing, a new promise, and a different CTA, a better result tells me nothing useful. It is just a new ad.

For a Shopify product, I usually start with four jobs:

Problem-first hook: name the frustrating moment a shopper recognizes.
Product-demo hook: show the product in use as quickly as possible.
Outcome hook: lead with the practical result, without inventing a claim.
Objection hook: answer the question I expect on a product page or in support.

The important part is that the jobs are specific enough to review. “Make it engaging” is not a test condition. “Show the application step in the first three seconds” is.

Why I Use a Script Contract Instead of Freeform Prompts

Freeform prompting is great for exploration, but it made our video output hard to compare. A reusable project in Supra UGC Maker gives me a better boundary: I can keep the scene and product reference, update the script or voice, preview the change, then reorder, trim, or regenerate only the clip that needs work.

Here is the script shape I use before I generate anything:

Hook: [one concrete customer moment]
Context: [what makes that moment annoying]
Product role: [what the product helps the shopper do]
Proof to show: [visible action or product detail]
CTA: [one next action]

It is deliberately short. I am not trying to make an avatar sound like a customer who used the product for six months. AI UGC-style video is best for scalable creative testing, explainers, launches, and visual variations; real creators are still the better choice when a campaign needs lived experience, community trust, or a genuine testimonial.

That distinction stopped me from writing claims the footage could not support. It also makes the handoff cleaner: someone reviewing the project can see what the video is meant to prove, not just what it happens to say.

The Review Gate That Prevents “Generated” From Becoming “Published”

I do not let a rendered clip go straight to an ad or product page. The review is small, but it catches the failures that make a fast workflow expensive later:

const review = {
  productMatchesReference: true,
  scriptMakesSupportedClaim: true,
  firstSecondsShowThePoint: true,
  sceneFitsTheBrand: true,
  ctaMatchesDestination: true
};

const readyToUse = Object.values(review).every(Boolean);

In practice, the failure mode is usually not the render itself. It is a mismatch: a premium product in a scene that feels off-brand, a voice that changes the intended tone, or a CTA built for an ad attached to a product-page clip. When that happens, I revise the one field that caused the mismatch rather than starting a new project.

This has also made reporting more honest. I can label a result by its tested variable—hook/problem-first or scene/studio—instead of trying to reconstruct the difference from a vague filename. That is a much better starting point for the next round.

Where the Videos Go After Review

The same approved concept can have different jobs across the store. A fast hook-led version can test in paid social; a slower product-demo version can help a Shopify product page; a compact version can become an email thumbnail or launch teaser. I wrote about the placement decision in this workflow for mapping one Shopify product into three UGC video jobs.

I still keep the destination in the contract because it changes what “good” means. A post-purchase video should reduce confusion. An acquisition ad should earn attention. That is why I would not reuse a winning hook blindly across every channel; the post-purchase use case deserves its own script and success criterion, as I found while planning support-oriented Shopify videos.

My Smallest Useful Starting Point

If you want to try this without building a whole creative-ops system, make one Supra UGC Maker project with one product, one customer problem, and four hook variants. Use a preset avatar or a custom AI model, choose a fitting scene, write each short script against the same contract, and preview before generating the final segments.

Then review the clips with the five checks above. Keep the project and scene reusable, but log the single variable you changed. You will have fewer “random variations,” more usable Shopify UGC videos, and a clearer reason for the next test.

TL;DR: Lock the product, problem, proof, and CTA. Change one creative variable at a time. Review before distribution. If you need a practical place to start, create your first UGC-style product video with Supra UGC Maker and tell me: which variable would you test first—hook, avatar, scene, voice, or CTA?

I Turned a Webflow CMS Site Into a Static Deployment Pipeline

Yassine — Sun, 16 Aug 2026 05:34:36 +0000

I was trying to hand off a Webflow marketing site without making its next edit a hostage negotiation. The design was done, the routes looked good, and the content team had finally filled the CMS. But the site still needed a deployment path our developers could own: files in a repository, a predictable preview, and hosting that was not tied to one dashboard.

The obvious move was a Webflow code export. Then I hit the part that matters: the native export includes HTML, CSS, JavaScript, and uploaded assets, but not CMS content or CMS functionality. A Collection list can become an empty state after export. That is exactly the kind of surprise that slips through when a team only checks the homepage.

So I treated this as a small deployment pipeline instead of a download button. Here is the workflow I use when I need a Webflow CMS site to become a static site without rebuilding the front end.

1. Separate the visual shell from the live behavior

I start by writing down what must survive the move. Static sites are fantastic for landing pages, documentation, portfolios, campaign pages, and other content that can be emitted as files. They are a poor drop-in replacement for everything that depended on runtime services.

That distinction is not theoretical. A standard code export includes the site shell and assets but not CMS data/functionality, user accounts, ecommerce databases and checkout, site search, password protection, or form processing. If the site needs any of those, I decide up front whether to replace that capability, preserve a hosted route, or change the scope.

For a content-heavy site, the question becomes: can I get every rendered CMS route and its media into the exported result? That is where ExFlow is useful. It is a Webflow exporter that can download a site from its URL and export all pages, CSS, JavaScript, images, and media; it is specifically useful when the standard code export is not enough for the CMS pages I need to preserve.

2. Export deliberately, not with every switch on autopilot

In ExFlow, I configure the export around the deploy target: all pages enabled, CSS/JS/media included, and .html extensions enabled when the destination expects them. If I am handing the result to a developer, I also add the small style.css or script.js overrides there rather than burying a last-minute tweak in a hosting control panel.

I keep sync credentials scoped and out of notes or repositories. ExFlow can sync to Git, S3, or FTP, but those credentials are sensitive deployment credentials—not something I paste into an issue or a shell history.

3. Audit routes like a user, not like a file browser

The export completing is not the definition of success. I look for the routes that prove CMS content survived:

a Collection list with real cards, not its empty state
two or three individual Collection pages
a filtered or linked page, if the site has one
an image-rich article or case study
a contact or gated page, so I can record any replacement work

For quick local smoke testing, I use a real web server rather than opening index.html directly. That catches relative-path mistakes and lets browser-dependent assets load in an environment closer to production. I load a homepage, one CMS-derived route, and a deep asset URL before I spend time on hosting details.

This is also where I check that internal links do not accidentally point back to a staging domain. If GitHub Pages is the eventual target, my earlier guide on hosting a Webflow site on GitHub Pages without rebuilding it is a useful next step once the static artifact passes locally.

4. Choose the deployment path that matches the team

I do not have a universal favorite; I use the path that makes rollback and ownership obvious.

Git sync works well when developers already review changes and deploy from a repository.
S3 sync is a good fit for a static asset pipeline and infrastructure-managed hosting.
FTP sync can be the least disruptive bridge for a traditional server.
Managed hosting is the simplest option when the team wants the export and host handled in one place.

ExFlow supports each of those sync options, so I choose one before exporting instead of doing a manual download and an unrelated upload later. Fewer handoffs means fewer chances to omit media or publish an older archive.

5. Run a boring production checklist

Before changing DNS or treating the new host as final, I check the boring things. They are boring right up until they are expensive:

Home, top navigation, footer, and a deep CMS URL return 200.
CSS, JavaScript, fonts, and key images load from production.
Canonical URLs, robots directives, and analytics are intentional.
Forms, search, authentication, and checkout have an explicit replacement plan.
A rollback path exists.

That form line deserves extra emphasis. A static copy can look perfect while its contact form silently does nothing. The right answer may be a third-party form endpoint, an embedded service, or keeping that route hosted differently—but it should be a conscious choice.

What finally made this feel safe

The win was not “I found a Webflow downloader.” The win was turning a one-off export into a repeatable pipeline: capture the rendered content, check the routes that matter, sync to the host the team owns, and test the live result. For a deeper final-pass sequence, this Webflow static-site cutover runbook complements the workflow nicely.

If you need to take a Webflow site—including CMS-driven pages—into a static hosting workflow, start with ExFlow, choose the export settings for your destination, and make the route audit part of the definition of done.

TL;DR: Exporting Webflow is easy; proving that the content, media, and runtime expectations survived is the real engineering work. What is the one Webflow feature that has made your team hesitate to self-host?

I Built a Shopify UGC Video Test Matrix Without Another Shoot

Yassine — Thu, 13 Aug 2026 09:34:25 +0000

I was trying to answer a deceptively simple question for a Shopify launch: which creative angle should we make next?

The old answer was expensive. Brief a creator, ship product, wait for footage, get one interpretation of the hook, then repeat. That is still a great route when you need a real creator's credibility or a true customer story. But it is a painfully slow feedback loop when I only need to compare a product demo, an objection-handling script, and three different opening lines.

So I stopped treating every new video as a mini production. I built a small, review-first test matrix around Supra UGC Maker, a Shopify app that can combine avatars, scenes, product references, scripts, and voice/tone into UGC-style video segments. The goal was not to pretend an AI avatar was a customer testimonial. The goal was to make better creative decisions before I committed to another shoot.

The matrix: change one thing on purpose

My first failed attempt was a pile of prompts with vague names like new-final-v3. That is not testing; it is just generating. I needed each version to answer one question.

I now keep four explicit variables: hook, audience objection, scene, and CTA. For an insulated bottle, the matrix might look like this:

{
  "product": "insulated-bottle",
  "audience": "commuters",
  "variants": [
    { "hook": "My coffee is cold by 10am", "scene": "morning desk", "cta": "See the sizes" },
    { "hook": "One bottle for the whole commute", "scene": "train platform", "cta": "Pick a color" },
    { "hook": "I stopped carrying disposable cups", "scene": "cafe", "cta": "View the product" }
  ]
}

This is deliberately boring data. Boring data makes review easier. If a clip underperforms, I can point to the variable that changed instead of guessing whether the problem was the avatar, the script, the scene, or all three.

Supra UGC Maker gives me the building blocks I need for that experiment: I choose a preset avatar or custom AI model, select a scene, add the Shopify product when it fits, write the script, choose the voice/tone, and preview before generating. It also lets me reorder, trim, update, and regenerate clips inside a reusable project. That last part matters: a test matrix is only useful if I can make a second pass without rebuilding every asset.

Start with a narrow creative contract

I limit the first batch to three or four versions. Every version shares the same product, offer, and factual claims. I only vary the first two seconds and one supporting proof point.

That constraint protects me from a common failure mode: producing four clips that are so different that the results teach me nothing. If Version A is a calm desk demo and Version B is a loud sale announcement with a different offer, I have created two campaigns, not a clean test.

The contract I give myself is:

one product and landing page
one audience slice
one claim I can support
one primary placement
one changed variable per version

For a product page, the first line can address what the item does. For paid social, it can start with an interruption or a specific pain point. For email, I usually let the video support the message rather than make it carry the entire offer.

Keep the script useful, not overly polished

The best scripts in this workflow are short enough to inspect. I write a hook, one concrete benefit, one proof or use context, and one CTA. Then I read it aloud. If I would not say it in a product demo, I cut it.

That is especially important with AI UGC-style creative. It can be fast and flexible, but it should not invent customer experience, make unsupported performance claims, or cosplay a real endorsement. I use it for demonstrations, launch angles, feature explanations, and repeatable creative concepts. For hard-earned customer trust and personal testimonials, real creators are still the better tool.

I also put the source of truth next to the script: product title, approved claims, URL, and any words the narrator must avoid. It feels like a tiny content schema, but it prevents surprisingly expensive cleanup later.

Add a human review gate before distribution

Generation is not publishing. My last step is a review queue with three yes/no checks:

Is the product representation accurate?
Does the script match the approved offer and audience?
Does this placement need a different crop, CTA, or disclosure?

That queue is why I like treating video variants as artifacts rather than magical outputs. It is the same instinct behind an approval-gated Shopify catalog video queue: generation creates options; review decides what earns distribution.

Once a version passes, I can download it and place it where it has a job to do: an ad, a product page, a launch email, or a seasonal promotion. I do not assume the winner in one placement will win everywhere. The product-page version may need a slower explanation; the social version may need its payoff immediately.

What I measure before making more

I measure the next decision, not a vanity scoreboard. For a short paid test, that could be thumb-stop rate and click-through rate. On a product page, I care about whether shoppers reach the video and whether the page gets clearer, not merely whether the clip played. In email, I look at clicks to the relevant product or collection.

When a hook works, I keep it and test the next variable. That compounding workflow is how one Shopify product can turn into a week of deliberate experiments instead of a week of random assets. I wrote more about that handoff in my one-product UGC testing workflow.

TL;DR

I use AI UGC video generation to shorten the distance between an idea and a reviewable creative test—not to replace real customer voices. A small matrix, one changed variable, supported claims, and a human approval gate make the output far more useful than a folder full of unnamed videos.

If you want to try the workflow, start with one product and three hooks on Supra UGC Maker. What variable would you test first: the hook, the scene, or the CTA?

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?