Shopify project patterns we see on real merchant stores

Use these five anonymized scenarios to plan schema structure, export modes, and QA before you paste HTML into the converter. Each write-up reflects recurring project shapes from K2 Devworks client delivery — composites like our converter workflow case studies, not named merchants or invented testimonials.

Disclaimer: Merchant categories are labeled generically (e.g., fashion DTC). Details are blended from multiple projects. We do not publish client names without permission.

Scenario 1 — Fashion DTC seasonal campaign landing

Context

A direct-to-consumer apparel brand launches quarterly campaigns with new creative every six weeks. Design ships a full-width hero, editorial split modules, and a shoppable grid as static HTML from Figma. Merchants need to swap campaign copy, hero media, and collection links without developer tickets.

Challenge

Tight turnaround: four section types in three days. CSS uses asymmetric grids and overlapping images. Hardcoding URLs in HTML broke the previous theme when collections were renamed. Inline styles from the design export conflicted with theme typography tokens.

Approach

1. Split the landing HTML into hero (Flat), editorial splits (Flat), and product grid (Block with collection setting).
2. Paste each chunk into the converter — see hero guide and product grid guide.
3. Map hero video and poster images to separate settings with mobile fallbacks.
4. Scope all CSS to section.id; replace font sizes with CSS variables matching the parent theme.
5. Add presets per section so merchants assemble the campaign on a dedicated JSON template.
6. QA on mobile breakpoints and empty image states before handoff.

Outcome

Merchants manage campaign swaps in the theme editor. Developers retain one Git repo of section files reused across seasons. Export time per module dropped versus hand-typed schema; human review focused on brand tokens and lazy-loading images.

Scenario 2 — B2B wholesale catalog and quick order

Context

A wholesale merchant sells to approved buyers with SKU-heavy catalogs. Marketing wants a homepage module highlighting new lines, volume pricing callouts, and a quick-order CTA linking to the B2B portal. HTML prototypes include pricing tables and icon rows duplicated across categories.

Challenge

Buyers are not typical DTC shoppers — copy is technical, and settings must stay editable by operations staff, not only marketers. Repeatable category rows were hardcoded in HTML, so updates required developer deploys. Table markup needed accessible headers without breaking mobile layouts.

Approach

1. Convert icon + title rows using Block mode so operations can add categories.
2. Keep pricing disclaimers in richtext settings with maxlength guardrails — see schema guide for field types.
3. Use url settings for portal links; avoid javascript: handlers from prototype HTML.
4. Extract shared table styles into scoped CSS; test horizontal scroll on small screens.
5. Document which sections belong on index.json versus a dedicated landing template for training.
6. Validate with a B2B test account — gated content snippets stay outside section files.

Outcome

Operations updates category rows without deployments. Developers integrate once with the wholesale app boundary intact. Schema labels use plain language (SKU line, MOQ note) so non-designers trust the editor.

Scenario 3 — Beauty subscription PDP enhancements

Context

A skincare brand on subscription apps needs product detail modules: ingredient tabs, before/after sliders, and FAQ accordions beneath the buy box. Design delivers long single-page HTML; the live theme uses JSON product templates with app blocks for subscriptions.

Challenge

Third-party subscription widgets own part of the product form — new sections must not break app block slots. Accordion HTML repeated twelve FAQ items; merchants wanted dynamic add/remove. Image sliders used deprecated img_url patterns from an old theme export.

Approach

1. Convert FAQ markup with FAQ conversion in Block mode — one block per question pair.
2. Rebuild tabs as a section with blocks or settings per panel; reference tabs guide.
3. Replace img_url with image_url and image_tag per modern Liquid conventions.
4. Cap max_blocks on FAQs to keep editor performant on mobile admin.
5. Place sections below app blocks in product.json order array after staging tests.
6. Run Lighthouse on PDP with subscription scripts enabled.

Outcome

Merchants manage FAQs and ingredient content. Subscription app continues to render in its designated block. Developers ship scoped sections compatible with OS 2.0 product templates.

Scenario 4 — Legacy theme migration to Online Store 2.0

Context

A home goods store runs a pre-OS 2.0 theme with monolithic templates and includes. Leadership wants JSON templates, merchant-addable sections, and faster feature delivery. Hundreds of lines of legacy Liquid reference global snippets merchants cannot see in the editor.

Challenge

Migration risk: breaking live merchandising during peak season. Old sections mix presentation and business logic. Setting IDs from the legacy theme do not map 1:1 to new schema. Some includes hide hardcoded promotional copy merchants thought was editable.

Approach

1. Inventory templates and list sections to port versus retire.
2. Rebuild high-traffic homepage modules as OS 2.0 sections — use how sections work for JSON template wiring.
3. Map legacy settings to new IDs with a spreadsheet merchants can review.
4. Stage on a duplicate theme; compare rendered HTML before DNS cutover.
5. Use the converter for newly designed modules; hand-migrate critical legacy pieces with extra QA.
6. Publish internal docs for which presets replace old theme customization panels.

Outcome

Merchants gain Add section workflows on key templates. Technical debt from includes decreases. Migration completes in phases — homepage first, collection templates next — without a single big-bang launch.

Scenario 5 — Agency retainer: reusable section library

Context

A Shopify agency retains K2 Devworks to standardize section exports across ten client stores. Each client has different branding but similar module types: heroes, social proof strips, feature grids, and press logos. Designers deliver HTML; junior developers previously retyped schema inconsistently.

Challenge

Inconsistent setting IDs and CSS namespaces caused merge conflicts in shared Git workflows. Junior devs skipped presets, so merchants could not add sections. Agency needed a repeatable pipeline, not one-off hero files per client.

Approach

1. Define agency naming conventions for setting IDs and BEM-style class prefixes.
2. Train team on Flat vs Block — Flat vs Block article.
3. Standardize exports through HTML to Liquid Converter with shared validation checklist.
4. Maintain a ready sections starter set cloned per client theme.
5. Code review focuses on presets, empty defaults, and theme token alignment.
6. Track section export time before/after — agency reported faster junior onboarding.

Outcome

Agency ships client sections with consistent schema patterns. Merchants get working presets on day one. The retainer evolved into documentation and tooling training — the same philosophy behind our public guides.

How to use these scenarios

Match your project to the closest shape, then follow linked guides. For hands-on converter workflows, see HTML to Shopify section case studies. For who wrote this content, see our Shopify developers and development experience.

• Fashion DTC → prioritize image settings, presets, and campaign JSON templates.
• B2B wholesale → plain-language schema labels and Block rows for catalog modules.
• Beauty subscription → respect app block order and cap FAQ blocks.
• Legacy migration → phased JSON templates and setting ID mapping spreadsheets.
• Agency library → naming conventions plus converter validation as CI for juniors.

Methodology: how we write anonymized scenarios

Each scenario blends details from multiple projects with identifying information removed. We do not invent revenue lifts, star ratings, or quotes attributed to fake people. Instead we document challenge, approach, and outcome the way internal retrospectives work — so other developers can recognize their own project shape and plan schema work accordingly.

If a scenario matches your store, use it as a checklist, not a promise. Pair with development experience for expertise context and product origin for why we automate HTML-to-schema mapping. When in doubt, export a slice of your HTML in the converter and compare against the steps listed in the closest scenario.

Cross-scenario patterns

Despite different industries, five patterns recur. First: design HTML is never production-ready without schema mapping. Second: repeatables almost always need Block mode. Third: merchants need presets on JSON templates. Fourth: app blocks and third-party scripts dictate section order on PDPs and cart. Fifth: migrations succeed in phases, not single launches. Recognizing which pattern applies saves more time than debating Liquid syntax trivia.

• Hero and announcement modules → hero conversion guide.
• FAQ and accordion rows → FAQ conversion guide.
• Product grids and collection callouts → product grid guide.
• Full landing assembly → landing page case study.
• Schema fundamentals → schema guide.

What these scenarios deliberately omit

You will not find invented revenue percentages, fake merchant quotes, or logos of brands we never worked with. You will not find promises that one section file fixes SEO, conversion rate, or Core Web Vitals alone. Theme work is contextual — apps, catalog size, merchandising strategy, and brand guidelines all change outcomes.

We also omit proprietary client themes and unreleased merchant names. If you need implementation help on a scenario that matches your timeline, contact K2 Devworks with your theme stack and constraints. For self-serve learning, pair these scenarios with developer profiles and the free converter.

Suggested reading order

1. Read our story for company context and K2 Devworks background.
2. Skim scenarios on this page and pick the closest industry shape.
3. Open the linked conversion guide for that module type.
4. Export HTML in the converter and run the QA checklist from development experience.
5. Review in a staging theme before merge to production.