DEV Community: Yassine

A Lightweight Smoke Test for Shopify Size-Chart Rules

Yassine — Sat, 31 Oct 2026 10:31:14 +0000

A Lightweight Smoke Test for Shopify Size-Chart Rules

I was about to add one more collection rule to a Shopify size-chart setup when I noticed the uncomfortable bit: I could explain the rule in the admin, but I had not proved what a shopper would see. A lightweight smoke test fixes that. Before publishing, pick a small set of representative products, predict the chart each should receive, then check the rendered product pages—including one deliberate exception.

This is not a substitute for fit research or customer testing. It is a fast way to catch a chart silently landing on the wrong product because a collection, tag, or product type was broader than I remembered. For stores using Supra Size Chart, the useful ingredients are already there: central charts, rules by product, collection, type, vendor, or tag, and a theme app block that renders on the product page.

The problem: a rule can look right and still cover the wrong products

A rule engine is a great way to avoid pasting tables into every description. But catalog data is messy: a seasonal hoodie can inherit a tops collection; a product type can be renamed; a bundle can have its own fit. The more convenient the matching rule, the more important the exception check becomes.

I treat the smoke test as a tiny contract between the catalog and the storefront. Shopify describes metaobjects as reusable structured data, which is the right mental model here: the chart can be one reusable object, while the assignment still needs evidence that it belongs on each product family.

Build a five-product fixture, not a full-catalog spreadsheet

I start with five products. The exact count is not sacred; the goal is to represent the boundaries of the rule. For a Tops collection rule, my fixture might be:

Product	Why it is in the fixture	Expected result
Core tee	Normal member of the collection	Adult tops chart
Oversized hoodie	Same collection, different fit	Adult tops chart plus a visible fit note, if that is the store policy
Kids tee	Similar name but separate audience	Kids chart or no match
Gift bundle	Can inherit collection membership unexpectedly	Its own chart or no match
Archived sample	Edge case that should never render publicly	Not tested on the live storefront

The key is writing the expected result before opening the product pages. If I decide what looks acceptable after I see it, the test becomes a tour rather than a check.

For a more general pattern, I use the same small-fixture approach when planning a broad catalog change; I wrote about it in my Etsy bulk-edit planning workflow. Different platform, same discipline: define the intended change and the awkward cases first.

Check the three layers that actually affect the shopper

My smoke test has three passes. They are intentionally boring. Boring checks catch expensive surprises.

Data: open the chosen chart. Confirm its columns, units, notes, and measurement guide match the fit family. A chart with Chest and Length is not automatically useful for every product called a top.
Match: inspect why each fixture product matches. Is it the collection, a product-specific override, a product type, a vendor, or a tag? If two rules can apply, confirm the intended precedence rather than guessing.
Render: use a storefront preview or a safe test product to verify that the block appears where shoppers need it, the selected display mode is understandable, and the measurement guide is available with the numbers.

The last pass matters because an assignment can be technically correct but useless in context. A modal trigger hidden below a long product description is different from an inline chart near the size selector. Supra Size Chart supports inline, accordion, and modal treatments; choose the display pattern that matches the product page, then test that actual page rather than trusting the editor. The Shopify App Store listing documents those rule and display options.

Make failures actionable

When one fixture fails, I do not immediately patch the chart. I classify the failure first:

Wrong chart, right visibility: narrow the assignment rule or add a more specific one.
Right chart, wrong measurement vocabulary: split the fit family; a relaxed hoodie and a fitted tee may need separate guidance.
Right match, no storefront block: check the theme app block placement on the relevant product template.
Right chart but confusing choice: add a short fit note or measurement-guide label; do not pretend a numerical table answers an ambiguous fit question.

That classification prevents an easy-looking fix from becoming catalog debt. It also gives the next person a clear reason for the rule, which is valuable when a new collection arrives months later.

Turn the smoke test into a release habit

My release note is only four lines: rule changed, fixture products, expected outcomes, and actual outcomes. I rerun it when I add a collection, rename a product type, change a theme template, or import sizing data. CSV and JSON export are useful escape hatches, but they do not prove the customer-facing match; the storefront pass does.

This is the same lesson behind the static-export smoke test I added to another publishing pipeline: the smallest realistic check is usually more useful than a giant plan that nobody reruns.

TL;DR

A Shopify size-chart rule deserves a five-product smoke test before it reaches a collection launch. Predict the match, include an exception, verify data → rule → storefront, and write down failures by type. You will not prove garment fit with this process, but you will catch the avoidable problem of showing the wrong guide to the wrong shopper.

If you are setting up a rule-based sizing system, install Supra Size Chart, start with one fit family, and make the fixture list part of the launch checklist. What is the strangest product that has slipped through one of your catalog rules?

I Made a Static Framer Snapshot Before Launch Day

Yassine — Sat, 24 Oct 2026 14:25:51 +0000

I was two hours from launching a Framer campaign page when I noticed the uncomfortable part of a hosted-only launch: I had no deployable copy of the exact version we had approved. If an embed, domain change, or last-minute edit went sideways, our rollback plan was basically "open Framer and hope."

So I made a static snapshot before touching the launch controls. It was not a migration away from Framer. It was a portable, testable checkpoint that gave the team another way to preview, deploy, and recover the page.

Here is the workflow I now use.

Why I wanted a snapshot instead of a screenshot

A screenshot tells me whether the hero looked right at one viewport. A static snapshot has the files that make the page work: HTML, CSS, JavaScript, fonts, images, and media. That distinction matters for animated landing pages.

I wanted to answer a few boring but launch-saving questions before traffic arrived:

Can the page render outside its usual host?
Do navigation, CTA links, fonts, and responsive sections still work?
Is there a deployable artifact I can hand to another developer?
Can I test an alternate static host without rebuilding the page by hand?

That is a different job from moving a domain. If domain cutover is the immediate concern, this earlier write-up on mapping a Framer domain cutover is a useful companion. My goal here was narrower: capture a known-good release before launch day.

1. Freeze the version I am exporting

First I write down the published URL, the intended campaign path, and the time of the snapshot. Then I stop changing copy long enough to make the export meaningful.

That sounds fussy, but it stops a common failure mode: testing a static copy of yesterday's design while production contains a new form, script, or pricing card. For a campaign page, I also list third-party dependencies separately: analytics, forms, scheduling widgets, cookie tools, and video embeds. Those are usually the things that cannot be proven just by checking that the HTML loaded.

2. Export with the platform in mind

I use ExFlow's Framer exporter because the target is specifically a published Framer site. It can collect the page output, CSS, JavaScript, fonts, and media into static files, then let me download a ZIP or sync/deploy to Git, S3, FTP, or ExFlow Hosting.

The practical sequence is simple:

Enter the published Framer URL.
Run the export.
Keep the resulting archive as the release snapshot.
Put a copy on a preview host before treating it as a fallback.

A generic downloader can be fine for a tiny brochure page. I do not rely on one for a launch page with animations, lazy-loaded media, and responsive behavior, because those are the first details likely to become invisible breakage.

3. Test the artifact where it will actually run

I do not unzip the export, open index.html, and call it done. Browsers can be more forgiving locally than they are on a real host. Instead, I deploy the output to a preview URL and test it in the same shape as the eventual fallback.

For a quick local pass, this tiny server is enough to catch obvious relative-path problems:

npx serve ./framer-export

Then I use a real preview host. Git is useful when I want a versioned handoff; an S3 bucket or FTP server can fit an existing static-hosting setup; ExFlow Hosting is the shorter route when I do not need to manage another deployment target. The important part is that I can point a browser at the result without relying on the original Framer environment.

4. Run a launch-oriented smoke test

My checklist is intentionally more specific than "it looks good":

Visit the homepage and every campaign CTA.
Test navigation, footer links, and any redirect paths.
Check mobile and desktop breakpoints.
Wait for fonts, images, and video/media to finish loading.
Trigger animations and interactive sections.
Inspect page title, description, social preview metadata, and canonical URL.
Submit or deliberately test each form's failure behavior.
Open DevTools and look for failed network requests.

Forms deserve a special note. A static export can preserve the form UI while the form's backend requires its own configuration or verification. I test that explicitly rather than promising stakeholders that every hosted integration automatically follows the files.

5. Keep the snapshot useful after launch

The archive only helps if someone can identify it later. I name mine with the campaign and date, store it alongside the preview URL, and record which external services were tested. If I sync to Git, I add a short release note with the original Framer URL and commit hash.

This also makes handoff less mysterious. The next developer gets a concrete artifact and a list of known external dependencies, rather than an instruction to reverse-engineer a live marketing page. For a more deployment-focused follow-up, I previously documented exporting a Framer launch page to Git before a campaign.

ExFlow also has dedicated exporters for Webflow and Squarespace, but I prefer starting with the platform-specific workflow rather than pretending every site builder fails in the same way.

TL;DR

Before a Framer launch, I now create a static snapshot, deploy it somewhere testable, and smoke-test the real launch paths. It is not a substitute for a thoughtful domain plan or integration tests. It is a practical rollback and handoff artifact that removes one more unknown from launch day.

If you have used a static export as a launch fallback, what was the first thing that broke outside the original host?

I Planned a Safe Etsy Bulk Edit Before Touching a Listing

Yassine — Wed, 21 Oct 2026 16:33:39 +0000

I was staring at 186 Etsy listings that all needed the same seasonal cleanup. My first impulse was to select everything, change a few titles and tags, and call it a productive afternoon.

Then I remembered the last time a supposedly small catalog update leaked into listings with odd variation structures. The edit was technically successful. The cleanup afterward was not.

So I stopped treating bulk edits as a button and started treating them as a tiny deployment: define the change, make the target set explainable, test it on representative records, then verify the buyer-facing result. This is the workflow I use with Bulk Listing Editor for Etsy, which keeps the mechanics simple: search, select listings or variations, specify the modification, then run the bulk edit.

The rule that saved me: write one change sentence

Before I open a bulk-edit screen, I write the operation as one plain sentence. For example:

Add the material "linen" to all summer napkin listings in collection X.

Or:

Increase the price of the large variation by $2 for this product family.

If I cannot write that sentence without using and, I have more than one operation. Titles, tags, prices, photos, SKUs, inventory, descriptions, personalization settings, and variations are all valid candidates for batch work, but bundling unrelated modifications makes failures hard to locate.

That sentence also answers an important question: is this a listing edit or a variation edit? Whole-product fields belong to the listing; option-specific values such as a size, color, SKU, price, or quantity belong to a variation. I keep this listing-versus-variation decision guide nearby because choosing the wrong level is how a narrow change becomes a catalog-wide surprise.

Build a target set I can defend

A count is not a selection rule. “186 matches” may feel reassuring, but it tells me nothing about whether the right 186 records are included.

I start with the smallest filter that describes the intended set, then inspect enough results to find awkward cases: an old listing with a legacy title pattern, a product with more variations than usual, an item that is out of stock, and one with customized media. For a seasonal tag change, I am looking for listings that should not carry the tag; for a price update, I am looking for special cases that should not inherit the rule.

My stop condition is simple: I should be able to explain why any selected item is present and why a nearby item is absent. If that explanation turns into a story, the filter needs work.

Test the rule on a deliberately weird sample

I do not test on five ordinary listings. I want a sample that tries to break my assumption: one normal record, one variation-heavy record, one listing with a special price, one with a legacy SKU or title, and one item whose images are arranged differently.

That sample gives me a fast answer to questions the bulk UI cannot infer for me:

Does the title replacement damage a word in the middle of a phrase?
Did a tag get added twice, or did an old tag remain?
Does a variation-level price change stay limited to the intended option?
Are inventory, images, and personalization settings still sensible on the storefront?

For a more formal five-record pass, this Etsy bulk-edit test workflow is the same idea expressed as a repeatable checklist. The point is not process theater. It is avoiding an edit that is too broad to understand after it runs.

Separate listing work from variation work

Bulk Listing Editor has distinct Listings and Variations modes, and I use that separation as a safety boundary. In Listings mode, I use changes that apply to the product as a whole: titles, descriptions, tags, materials, images, or personalization settings. In Variations mode, I work on option-specific fields: sizes, colors, SKUs, prices, and inventory.

The tricky cases are mixed catalogs. A collection can contain a listing with “Blue / Small” and another with “Ocean / Mini.” They may mean similar things to a shopper, but a bulk rule should not pretend those are the same data model. I normalize or isolate inconsistent records before I include them.

This is also where I resist the urge to clean everything in one pass. If I need to rename an option, adjust its SKUs, and change its price, I make three small runs. That makes each result easier to verify and gives me a clear answer when someone asks what changed.

Run the real edit once, then inspect the storefront

Once the test batch passes, I repeat the same search criteria, expand the selection, and run the one planned modification. I record the date, the exact change sentence, the affected count, and a handful of listing URLs. That is enough of an audit trail for a small shop without inventing a new operations system.

Afterward, I open representative listings as a buyer would. I check:

the visible title and description
the selected variation and its price
stock and SKU behavior where it matters
image order and the first gallery image
tags, materials, and personalization options

The storefront check matters because a batch editor can confirm that it applied a request; it cannot tell me whether the resulting page still communicates the right thing to a person shopping.

The trade-off: slower starts, much faster recovery

This workflow adds perhaps ten minutes before a large edit. It is not ideal when I genuinely need an emergency catalog correction. But most “urgent” bulk updates become expensive because the selection rule or scope was unclear, not because the button took too long to click.

Bulk Listing Editor is especially useful when the same cleanup pattern repeats across listings or variations. It has a seven-day free trial and an $8/month subscription, so I would use the trial to run one real, tightly-scoped catalog task—not a random mass edit—to see whether the three-step workflow fits the shop’s data.

TL;DR

I plan a safe Etsy bulk edit by writing one precise change sentence, choosing the correct listing or variation level, testing the rule on awkward records, then checking the buyer-facing result after the full run.

My next action is to pick one repetitive catalog chore and run a five-listing test before touching the rest. What is the one Etsy change you keep postponing because doing it manually feels safer?

I Turned Shopify Objections Into Video Briefs With a Tiny YAML Schema

Yassine — Mon, 19 Oct 2026 02:28:13 +0000

I was trying to make a short product video for a Shopify store whose customers kept asking one question: Will this actually work for my use case?

My first instinct was to write a clever hook and generate a few AI UGC variations. That produced videos, but not necessarily answers. The problem was upstream: the customer objection was sitting in a support inbox, while the video prompt was a vague paragraph in another tab.

I fixed that by treating each objection as input data. A tiny YAML schema now turns a customer question into a reviewable video brief before I open the generator. It is deliberately small enough to edit by hand, but structured enough to stop the usual \"make it engaging\" drift.

Supra UGC Maker is a useful fit for this workflow because its projects let me combine an avatar, scene, product reference, script, voice/tone, and reusable clips. The schema is not tied to one tool, though; it is the boundary between a customer problem and any video-production system.

The brief is the interface

Here is the format I started with:

yaml\nproduct: insulated travel mug\naudience: commuter who wants coffee to stay hot\nobjection: \"I do not want another mug that leaks in my bag.\"\nvideo_job: product-page explainer\nhook: \"My laptop bag survived this commute.\"\nproof:\n - show closed lid beside a backpack\n - show lock mechanism close-up\n - state the real cleaning limitation honestly\nscene: bright kitchen counter\navatar_tone: calm, specific, not overhyped\ncta: check the lid details before choosing a size\nreview_checks:\n - product is shown accurately\n - claim is supported by the product information\n - hook and proof address the same objection\n

This is not a prompt replacement. It is a contract. The objection, hook, and proof fields must agree, or I do not generate the clip. The explicit video_job also prevents an ad-style opening from accidentally becoming the only thing on a product page.

Why the fields are boring on purpose

The schema has a few rules that sound almost annoyingly obvious:

One objection per brief. \"People may not trust the price, fit, material, or shipping\" is four briefs pretending to be one.
One observable proof. If I cannot name the shot, demo, or supported explanation that earns the claim, it is marketing fog.
One job. An ad can earn a click; a product-page explainer can reduce uncertainty. Asking fifteen seconds to do both usually weakens both.
A stated limitation. I do not want an AI avatar inventing certainty. A real constraint in the brief gives the reviewer something concrete to protect.

I had already learned the value of structured inputs when I replaced an ad-video spreadsheet with a tiny JSON contract. YAML is more convenient for this particular stage because a marketer can change a sentence without fighting JSON punctuation. When the brief becomes application data, I can validate it or convert it later.

Compile the brief into variants, not random options

Once a brief passes review, I create variations by changing one variable at a time. For example, the same leak objection can have a commuter kitchen scene, a train-platform scene, or a close-up product demo. The proof remains the lock mechanism.

That distinction matters. Changing avatar, scene, hook, proof, and CTA in every generation gives me four different videos but almost no learning. I prefer a compact matrix:

Variant	Change	Constant
A	avatar	objection and proof
B	opening hook	product demo and CTA
C	scene	script claim and proof
D	CTA	hook and proof

This is a narrower version of the test harness I described in I Turned Shopify UGC Creative Into a Small Test Harness. The important change is that the customer objection is now a required field, not just a note in the campaign.

Feed it into the video project

In Supra UGC Maker, my handoff is straightforward:

Pick the Shopify product or add its reference.
Choose an avatar and scene that make the proof easy to see.
Turn hook, proof, and cta into a short script.
Set the voice/tone from the brief rather than improvising a personality.
Preview the scene, generate a segment, then reorder, trim, update, or regenerate inside the project.

The tool can save reusable scenes and projects, which is especially helpful once the schema starts producing consistent briefs. I can reuse a product-demo scene without reusing the same unsupported sales claim.

Put a human gate after generation

The failure mode here is not that the model produces a bad video. It is that a smooth video makes a weak claim feel finished. I review each export against the source brief:

text\n[ ] Is the product behavior shown or accurately explained?\n[ ] Does the spoken claim match the approved proof?\n[ ] Could a shopper mistake a styled scene for product evidence?\n[ ] Does the CTA fit the video job?\n[ ] Did we preserve the stated limitation?\n

Real creators are still the better choice when community trust, a genuine testimonial, or a personal creator relationship is the actual asset. AI UGC-style video is most useful to me for scalable creative testing, explainers, and fast first passes—not for impersonating lived experience.

TL;DR

A customer objection is a much better starting point than \"make a UGC ad.\" Capture one objection, one product-specific proof, one video job, and one reviewable CTA in a tiny YAML file. Then use an AI UGC video generator to create controlled variations, not an untraceable pile of clips.

My next step is to add a source_url field so every brief points back to the support ticket, review theme, or product documentation that justified it. What field would you add before letting a video brief reach production?

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?