Customizing native sections vs building custoom sections from scratch

Hello everyone,

When a client request a highly customized layout, do you usually prefer modifying Dawn’s native section and override the CSS or do you clean slate it and create entirely custom sections from scratch using liquid and schema? I wanted to know your opinions if you work extensively with Shopify Dawn’s theme.

What are the advantages and disadvantages of these advantages for long-term maintenance.

Hey @angelina-new-user

My rule is simple: if it’s a styling change, override the CSS on the native section, and if it’s a structural change, build a new section from scratch. The trap is the middle ground, where you start editing a native section’s Liquid and schema to force a different structure, because then you’ve got a file that’s neither stock nor yours, and every theme update turns into a merge conflict you have to resolve by hand.

Best,
Moeed

Hi @angelina-new-user
For long-term maintenance, I’d avoid heavily modifying Dawn’s native sections when the requested layout is significantly different from the original structure. Small visual changes can stay on the native section, but once you’re changing the markup, schema, or section logic substantially, I’d create a separate custom section.

That keeps the original Dawn code easier to update and makes the custom functionality easier to maintain or troubleshoot later. I’d also keep the schema clean and configurable so the client can manage the section from the Theme Editor without needing code changes for every small update.

Hi @angelina-new-user

For long-term maintenance, I’d also recommend:

  • Reuse Dawn’s CSS variables/tokens instead of hard-coding design values.
  • Keep section-specific CSS and JS scoped to that section.
  • Avoid modifying core Dawn files unless absolutely necessary.
  • Keep the schema flexible so merchants can control content from the Theme Editor.
  • Use Shopify’s native responsive image handling instead of manually managing image sizes.
  • Separate reusable logic into snippets instead of duplicating Liquid.
  • Keep custom JavaScript modular and avoid global event listeners where possible.
  • Document major customizations so another developer can understand the architecture later.

The biggest mistake is trying to make a native Dawn section behave completely differently through hundreds of CSS overrides. If you’re fighting the original DOM structure, that’s usually a good indication that a custom section is the cleaner solution.

So my rule is: extend Dawn when the structure fits; build a custom section when the structure doesn’t. This gives you the best balance between Dawn compatibility, performance, flexibility, and long-term maintenance.

Best regards,
Devcoder :laptop:

Hey @angelina-new-user, one practical reason behind “avoid modifying core Dawn files”: if you edit Dawn’s own section/liquid files directly, any future Dawn update conflicts with your edits in that same file. A new custom section sitting alongside untouched Dawn files means Dawn updates apply cleanly and your custom work is unaffected either way. On client builds that upgrade path is usually the deciding factor for us, more than the extra build time.

Hi there @angelina-new-user
I typically begin with Dawn’s native sections if the structure is close to what is required, then apply Liquid, schema, and targeted CSS for the variances. This makes for easier maintenance and future theme updates, in most cases.
For layouts that are significantly different I prefer to build a custom section rather than a radical override of the existing markup. It makes the code more predictable and there are fewer CSS conflicts.

A good rule of thumb is to leverage Shopify’s existing patterns where possible and keep any truly unique features contained in custom sections.