How to Build and Customize a Shopify Theme: A Practical Guide for Thai Stores

"Build a Shopify website" almost always means "pick a theme and customize it" — Shopify doesn't really have a from-scratch website builder in the way that phrase implies. The actual work is a series of decisions: which base theme to start from, what can be changed safely in the Theme Editor without touching code, and what genuinely requires a developer writing Liquid. Getting that sequence backwards is where most self-built Shopify stores end up stuck.

Start with the right base theme, not a blank one

Every Shopify store starts from a theme, and the two free reference themes — Dawn and Horizon — sit at different points on a real trade-off, not just a style choice. Horizon is now the default theme for newly created stores, built with modern web components, global blocks that let you edit shared elements site-wide at once, and AI-assisted section generation through Shopify Magic. Dawn, the older reference theme, is lighter and measurably faster — a clean Horizon demo has been benchmarked meaningfully slower on mobile PageSpeed than an equivalent Dawn setup, a real gap on the same hardware and content.

The practical implication: a new store prioritising editing flexibility and willing to manage performance actively can reasonably start on Horizon. A store that's already live, performing well, or running several apps that haven't been tested against Horizon's newer component architecture has a real reason to stay on Dawn rather than migrate for the sake of using the new default.

Why some apps break specifically on Horizon

This is worth flagging on its own, because it's a genuine, non-obvious compatibility issue: Horizon's variant picker, gallery and cart drawer are built as web components running inside Shadow DOM, which isolates their internal markup from the rest of the page. Older apps that inject content by directly targeting theme HTML — a common integration pattern for years — can silently fail to attach inside that isolated boundary. Before migrating an existing store to Horizon, or choosing it for a new store with a must-have app already picked out, checking that app's actual compatibility is worth doing before committing, not after the migration.

What Online Store 2.0 actually changed

Themes built on the Online Store 2.0 architecture — which includes both Dawn and Horizon — are structured around sections, blocks, and metafields, and understanding this structure is the difference between confidently customizing a store and guessing:

• Sections are reusable content modules — a hero banner, a product grid, a testimonial strip — that can be added, removed, and reordered on any page directly through the Theme Editor, without editing code.
• Blocks live inside sections and control the smaller repeating pieces — an individual testimonial, a single image in a gallery — giving merchants granular control within a section's structure.
• App blocks let apps insert their own functionality directly into a section through the same editor interface, rather than requiring a developer to manually place app code into theme files.
• Metafields attach structured custom data — a size chart, a care guide, a certification badge — to products, collections or pages, and themes built for Online Store 2.0 can display that data without custom development for each new field.

Most of what a merchant wants to change on a modern Shopify theme — content, layout order, imagery, basic structure — is a Theme Editor task now, not a code task. That's the actual promise of Online Store 2.0, and it's genuinely delivered for a large share of common requests.

What still needs a developer

Theme Editor customization has real limits, and knowing where they are saves a lot of wasted time trying to force the editor to do something it isn't built for:

• Custom sections or blocks that don't exist yet. If the layout or interaction you want isn't one of the theme's built-in section types, it needs a custom .liquid section written and added to the theme.
• Logic that depends on conditions — showing different content based on customer tags, order history, or inventory thresholds — needs Liquid templating logic, not just editor configuration.
• Deep checkout customization on Shopify Plus, or anything touching cart or checkout behaviour beyond branding, is developer territory.
• Performance work — trimming unused JavaScript, fixing a Core Web Vitals regression introduced by a theme or app — requires someone who can actually read the theme's code, not just the editor's settings panel.

The development workflow, if you're building it yourself

For a technical team or a developer taking this on directly, the standard workflow is worth following rather than improvising: install Shopify CLI, clone a base theme locally with shopify theme init, and develop against a real development store rather than editing the live theme directly. Theme Check, Shopify's own linter, catches common mistakes and anti-patterns before they ship. Version control through GitHub, plus a proper editor like VS Code with Shopify's Liquid extensions, is standard practice — not an optional extra step for a "real" project versus a hobbyist one.

The mistake that causes the most damage: editing the live theme directly

The single most common way a Shopify customization project goes wrong is someone editing the theme that's currently live, in the Theme Editor or the code editor, while the store is actively taking orders. A typo in Liquid code, a section moved incorrectly, or a broken template can go live instantly and stay broken until someone notices. Shopify lets you duplicate a theme and work on the copy — publishing only when it's actually ready — and that one habit prevents the majority of "the site broke and we don't know why" incidents we see.

Where Thai stores need extra attention

A theme customized well by generic standards can still fall short for a Thai audience in specific, fixable ways:

• Thai typography needs testing with real Thai text, not Latin placeholder copy swapped in at the end — line height and font choices that look correct for English often crowd Thai vowel and tone marks that stack above and below the baseline.
• PromptPay and COD need to be visible, not buried. A theme's default checkout branding options can surface Thailand's actual preferred payment methods clearly if configured deliberately — this is a setup detail worth getting right during customization, not an afterthought.
• Mobile performance matters more here than the global average, given how much Thai ecommerce traffic runs on mid-range Android devices over mobile data — which is part of why the Dawn-versus-Horizon performance gap is a genuinely relevant decision factor for a Thai store, not a minor technical footnote.

A practical way to plan the work

1. Decide Dawn or Horizon based on your actual priorities — editing flexibility and AI-assisted sections, or proven speed and broader app compatibility — not just which one is the new default.
2. List what you actually need to change, and sort each item into "Theme Editor" or "needs custom code" before starting, rather than discovering the split halfway through.
3. Always customize on a duplicated theme, publishing only once it's been checked, never editing what's currently live.
4. Test with real Thai content and on a real mid-range Android device before calling the customization finished.

The takeaway

"Building a Shopify website" is genuinely achievable without a developer for a large share of what most stores need, because Online Store 2.0 put real customization power into the Theme Editor. The businesses that get frustrated are usually the ones that picked the wrong base theme for their priorities, or tried to force the editor to do something that was always going to need actual Liquid code — knowing which is which before you start is most of the battle.