Shopify Theme Development Tutorial: Liquid vs Online Store 2.0 in 2026

A Croatian shelving retailer landed on our desk with a catalogue that lived in PDFs. Their customers were buying steel racks by load capacity per shelf and total system weight, and the only way to get those numbers was to download a spec sheet or phone the office. The question they asked us was deceptively simple: could we build a Shopify store where a first-time visitor goes from “I need shelves for my garage” to a finished order without talking to anyone. That question is really a theme development question, and the answer forced us to pick between two very different ways of building a Shopify theme in 2026.

This Shopify theme development tutorial is a comparison, not a walkthrough of one method. We are going to put the two live approaches side by side as we actually use them on client work: writing a theme by hand in Liquid from something like Dawn, versus building on the Online Store 2.0 sections-everywhere architecture with metafields and the theme editor doing the heavy lifting. We will tell you which one we reached for on the shelving build, where it bit us, and how we decide on every project that comes in.

TL;DR

• OUR POSITION: For most stores, including technical and B2B catalogues, an Online Store 2.0 build extended with custom sections and metafields is the correct default, not a hand-rolled theme. We only go fully custom when the merchandising model genuinely cannot be expressed in sections, and that is rarer than most guides pretend.
• THE REAL SKILL: Shopify theme development in 2026 is less about mastering every Liquid tag and more about deciding what belongs in code, what belongs in metafields, and what belongs in the theme editor where a non-technical merchant can change it without calling you.
• WHAT MOVED THE NUMBER: On the Metalne Police build we treated product specifications as the interface itself, browse by space, filter by size and load capacity, answer the fit question on the product page. That editorial decision, not the theme framework, is what increased conversions by 18% compared to their previous setup.

The Two Approaches, Side By Side

Before we argue for one, here is how the two paths actually differ in the day-to-day of building and handing off a store. This is the table we sketch on a call when a client asks why one quote is higher than another.

Criterion	Hand-coded Liquid theme (from Dawn or scratch)	Online Store 2.0 sections + metafields
Initial build speed	Slower, you own every template	Faster, sections and blocks are reusable
Merchant self-service after launch	Low, most changes need a developer	High, merchant edits in the theme editor
Structured product data	You build the plumbing yourself	Metafields and metaobjects, native
Handling unusual merchandising	Total freedom, total responsibility	Constrained to the section model
Long-term maintenance cost	Higher, custom code drifts	Lower, closer to platform defaults
Upgrade path (theme updates)	Painful, you diverge from the base	Cleaner, if you stay disciplined
Typical Presta build window	5 to 9 weeks (our estimate)	3 to 6 weeks (our estimate)

Those build windows are Presta estimates from past projects, not measured guarantees. They shift with catalogue size, integrations, and how much of the design is genuinely novel. The point of the table is the shape of the trade-off: hand-coded Liquid buys you freedom and costs you time and future flexibility for the merchant; Online Store 2.0 buys you speed and self-service and costs you some raw control.

The first thing we check when a store like Metalne Police comes in is not “which framework.” It is “what does the customer need to know before they can buy, and where does that information live today.” For them it lived in PDF spec sheets. That single fact told us the theme’s job was to surface structured data, dimensions, load capacity per shelf, total system weight, at the exact moment a buyer is deciding. Whichever approach answers that question with the least custom code wins the default.

Checks we run before choosing a path:

• Catalogue shape: How many product types, and do they share attributes or diverge wildly.
• Data source: Is product data structured anywhere already, or trapped in PDFs and spreadsheets.
• Merchant capability: Will the client’s own team run this daily, and how technical are they.
• Change frequency: How often will pages, promotions, and layouts need to change after launch.
• Integration load: Is there an ERP or feed that dictates how data arrives.

Hand-Coded Liquid Themes: Building From The Metal Up

When people search for a Shopify theme development tutorial and imagine “real” development, this is usually what they picture: opening the theme files, writing Liquid, controlling every template, section, and snippet by hand. It is genuine engineering, and there are projects where it is the only honest answer.

We reach for a hand-coded approach when the merchandising logic is the product. If a store needs a configurator where selecting a shelf width changes available depths, which changes the load rating shown, which changes the price, that branching logic does not live comfortably inside stock sections. On the shelving build we seriously considered going fully custom for exactly this reason, because the fit-and-capacity question is conditional. A 200cm upright supports different shelf loads than a 250cm upright, and showing the wrong number is not a cosmetic bug, it is a safety and returns problem.

What talked us partly out of full custom was maintenance. The client told us plainly through their CEO that their customers are old school and need a very straightforward, easy way of shopping. That is a hint about the merchant too. Their internal team is not a group of developers waiting to edit Liquid. If we hand-code everything, every seasonal change, every new product family, every “can we move this block up” becomes a Presta ticket. That is good for our invoices and bad for the client, and we would rather keep clients because the store works than because they are trapped.

When is hand-coded Liquid actually the right call?

It is the right call when the section model cannot express the interaction without ugly workarounds, when the design is genuinely bespoke and pixel-exact in a way stock blocks fight against, or when performance is so tight that you need to strip everything unnecessary out of the theme. We have shipped hand-tuned templates for exactly these reasons. What we no longer do is start from a blank theme out of habit. We start from Dawn and diverge only where we must, which keeps us close to the platform’s own updates. Shopify’s own theme architecture documentation is worth reading before you decide how far to stray from it, because every custom section you add is something you now own forever.

Advantages of hand-coded Liquid:

• Total control over markup, so you can hit exact design and performance targets.
• No fighting the section model when your interaction logic is genuinely conditional or nested.
• Cleaner, smaller output when you strip everything the store does not use.
• Full ownership of edge cases like unusual variant structures or custom cart logic.

Limitations of hand-coded Liquid:

• Every change after launch tends to route back through a developer, which slows the merchant down.
• You drift from the base theme, so platform updates and new features get harder to adopt.
• Higher long-term cost, because custom code needs custom maintenance.

Checks we run on a hand-coded theme before we commit:

• Divergence budget: How far are we straying from Dawn, and can we justify each departure.
• Handoff reality: Who edits this after launch, and can they without us.
• Variant complexity: Do the conditional rules actually need code, or just good metafields.
• Performance target: Are we going custom for speed, and can we prove the gain.
• Update tolerance: Can this client afford to skip platform features to keep their custom build stable.

Online Store 2.0: Sections, Metafields, And Merchant Self-Service

Online Store 2.0 changed the default answer to most theme questions. Sections everywhere means nearly every template, not just the homepage, is built from sections and blocks a merchant can rearrange in the theme editor. Metafields and metaobjects give you structured, typed data attached to products, collections, and pages, rendered natively in Liquid. For a catalogue like Metalne Police, this is not a convenience, it is the whole architecture.

Here is the decision that mattered. Every shelf has dimensions, a load capacity per shelf, and a total system weight. In the old world you either dumped that into the product description as free text, which is unfilterable and inconsistent, or you built custom fields and custom rendering by hand. We modelled each spec as a metafield with a defined type and unit, then built product-page sections that read those metafields and present them as a clean spec block, not a paragraph. The buyer sees the numbers where the decision happens. The filtering by size and load capacity is driven by the same structured data. Nobody at the client has to touch Liquid to add a new shelf, they fill in the fields.

That is the payoff of choosing sections and metafields over hand-coded plumbing: the interface and the data stay honest to each other. We wrote more about why Shopify’s structure suits this kind of long-lived catalogue in our note on architecting ecommerce for the next decade, and the shelving build is the clearest example of it we have shipped.

Treat specifications as the interface, not as an afterthought buried in the description. Numbers are why people buy shelving, so we put the numbers where the buying happens.

We saw the same principle pay off on a baby and childcare retailer, Beberusha. That was not a ground-up build, we tweaked an existing Shopify store, and a meaningful part of the work was tightening how product information and merchandising surfaced through the theme’s existing sections rather than rebuilding anything. They increased revenue by 30% in the first month. When the architecture is already sections-based, improvement can be fast because you are editing structure, not excavating custom code.

Do metafields really replace custom code?

Not entirely, and pretending they do is how people ship brittle stores. Metafields replace the plumbing for structured data. They do not replace genuine application logic. On the shelving store, metafields carried the specs beautifully, but presenting a spec comparison table across variants still needed section code that read and laid out those fields intelligently. The right mental model is that Online Store 2.0 handles the “what data exists and who can edit it” problem, and you write focused Liquid only for the “how is this specific thing presented” problem. That division keeps the custom surface small and the merchant in control. Shopify’s metafields documentation lays out the types available, and choosing the right type up front saves a painful migration later.

Advantages of Online Store 2.0:

• Merchants edit layout, content, and structured data themselves after launch.
• Metafields and metaobjects give you typed, filterable product data without custom plumbing.
• Faster builds and faster iteration, because sections are reusable across templates.
• You stay close to the platform, so new Shopify features land with less friction.

Limitations of Online Store 2.0:

• The section model can feel constraining when your interaction is genuinely conditional.
• Poorly planned metafields become a mess that is expensive to restructure later.
• Complex presentation still needs real section code, so it is not zero-development.

Checks we run on an Online Store 2.0 build:

• Metafield schema: Are types and units defined before anyone enters data.
• Section reuse: Are we building generic sections, or one-offs that defeat the point.
• Editor guardrails: Have we set sensible block limits so merchants cannot break layouts.
• Filterable data: Is every attribute a customer filters on stored as structured data.
• Presentation code scope: Is our custom Liquid focused only on how data is shown, not what it is.

The Structured-Data-First Framework: How We Actually Build These

Across the shelving build and the technical catalogues that came after it, we settled into a repeatable way of working. We call it building structured-data-first, because the order you do things in decides how painful the rest of the project is. Skipping straight to design is the single most common mistake we see in DIY Shopify theme development, and it is why so many tutorials produce a pretty store that cannot filter or scale.

STEP ONE, MODEL THE DATA. Before any pixels, we list every attribute a customer needs to make a decision and every attribute they filter or sort by. For shelving that was dimensions, load capacity per shelf, total system weight, material, and use case. Each becomes a metafield or metaobject with a defined type. This is the least glamorous step and the one that pays off for years.

STEP TWO, MAP THE JOURNEY TO THE DATA. We organise the catalogue by how people actually shop, which for this client was by space and use case, garage, workshop, warehouse, not by internal SKU logic. Collections and navigation follow the buyer’s mental model. This is where we decided browse-by-space would be the primary entry point.

STEP THREE, BUILD SECTIONS THAT READ THE DATA. Now we build theme sections, and only now, because we know exactly what they need to render. The spec block, the filter set, the comparison view, each one reads the metafields defined in step one. Custom Liquid stays scoped to presentation.

STEP FOUR, HAND THE KEYS OVER. We configure the theme editor and metafield entry so the client’s own team can add products and adjust layout without us. On the shelving build this was non-negotiable, given how plainly the client said their team needed simplicity.

STEP FIVE, MEASURE AGAINST THE OLD SETUP. We instrument the store to compare against the previous experience, because “it looks nicer” is not a result. For Metalne Police the number that mattered was conversion, and it moved 18% versus the old setup.

We got the sequencing wrong on an earlier, unrelated project once, where we designed the product page first and retrofitted metafields into it afterwards. We ended up rebuilding two sections because the data types did not match what the design assumed, and we quietly ate the overrun. Now the data model comes first, always, and we scope it that way in the quote.

Checks we run through the framework:

• Attribute inventory: Is every decision-driving and filterable attribute captured before design.
• Buyer-first taxonomy: Does navigation follow how customers shop, not internal SKU logic.
• Scoped presentation code: Is custom Liquid limited to rendering, not data definition.
• Merchant handoff test: Can a non-developer add a product end to end.
• Baseline comparison: Are we measuring against the previous setup, not against nothing.

Integrations And Data Sources: The Part Themes Do Not Solve Alone

A theme renders data. It does not create it. On any catalogue with real operational weight, the harder question is where the product data comes from and how reliably it arrives, and this quietly decides how much freedom your theme choice really has.

We learned this most sharply on a dental and medical equipment retailer, Tehnodent, a technical B2B catalogue much like the industrial storefronts we build. That was a WooCommerce state-of-the-art store with ERP integration, and it increased their revenue by 80%. The theme work there was inseparable from the integration work: the ERP was the source of truth for products, stock, and pricing, so the storefront had to render whatever the ERP sent, cleanly, including the fields a technical buyer needs. We saw the same pattern on a cosmetics and personal care brand, Cosmetica Labs, where we built a Shopify state-of-the-art store with ERP integration and revenue rose 80%. In both cases the lesson was identical: if the ERP is the source of truth, your theme’s job is disciplined presentation of external data, and you plan your metafields to match the ERP’s fields rather than inventing your own.

This is where we have watched integrations quietly sabotage clean theme work. An ERP export that carries the wrong VAT flag, or a feed that sends dimensions as a single free-text string instead of separate values, forces you to either fix the data upstream or write defensive parsing in the theme. We fix it upstream every time we can, because parsing rubbish in Liquid is how you get a store that breaks on the one product that has four variants instead of three. On the shelving build the data was cleaner because it was new, but we still defined the metafield structure to match how the client actually maintains their catalogue, not how a spreadsheet happened to be laid out.

The comparison holds here too. An Online Store 2.0 approach makes ERP-driven catalogues easier, because metafields give you a natural, typed home for every field the ERP sends. A hand-coded theme can do it, but you build all that mapping yourself. This is one more reason our default leans toward sections and metafields for technical catalogues.

Checks we run on integrated catalogues:

• Source of truth: Is the ERP or the store authoritative for each field, decided explicitly.
• Field mapping: Does every metafield map to a real, reliable ERP field.
• Data hygiene: Are we fixing bad data upstream instead of parsing it in the theme.
• Failure behaviour: What does a product with missing or malformed data render as.
• Sync cadence: How often does data refresh, and does the theme assume it is live.

Build It Right Or Fix It Later: Talk To Presta’s Ecommerce Team

If you are building a technical or spec-heavy Shopify store, or you have one that looks fine but cannot filter, compare, or let your own team edit it, our ecommerce team does exactly this: Shopify, WooCommerce, and Shopware builds, platform migrations, and the ERP and feed integrations that make the data behind the theme reliable. The shelving build in this article is the kind of work we take on, structured-data-first, handed off so your team can run it.

This is for operators who sell on numbers and want the store to do the explaining. It is not for someone who needs a five-page brochure site, you do not need us for that. If your catalogue is technical, your data lives in an ERP or spreadsheets, and the theme is the bottleneck, that is our threshold. Tell us what you are building and we will tell you honestly whether it is a tweak or a rebuild.

Which Should You Choose: A Decision Framework

Here is how we actually decide, mapped to situations we have handled rather than abstractions. We are not going to say “it depends” and leave you there.

If your merchandising is conditional and interactive, a configurator where one choice changes the valid options and pricing for the next, lean hand-coded Liquid, but keep it based on Dawn and scoped tightly. This is the shelving case where we considered full custom for the fit-and-capacity logic. We ended up doing a hybrid: metafields for the data, focused section code for the conditional presentation.

If your catalogue is spec-heavy but the interactions are conventional, choose Online Store 2.0 with metafields. This was most of the shelving build, and it is where we land for the majority of technical catalogues. The data is structured, the presentation is rich, but you are not branching logic dynamically on the page.

If your team will run the store daily and is not technical, choose Online Store 2.0, almost regardless of anything else. The Metalne Police CEO’s point about needing something straightforward applies to the merchant as much as the customer. A store your team cannot edit is a store that decays.

If you are migrating from another platform, decide the theme approach as part of the migration, not after it. We cover this in our guide on how to migrate from WooCommerce to Shopify in 2025, and the short version is that migration is your one clean chance to model data properly, so use Online Store 2.0 and get the metafields right while you are moving anyway. If you are weighing the platforms themselves, our complete guide to WooCommerce to Shopify benefits sets out the trade-offs, and the wider view of turning migrations into growth stories is where theme and data decisions actually earn their keep.

Here is the mapping in one table, drawn from situations we have run.

Your situation	Approach we choose	Why
Conditional configurator logic	Hybrid: metafields + custom sections	Section model alone cannot branch cleanly
Spec-heavy, conventional interactions	Online Store 2.0 + metafields	Structured data, merchant self-service
Non-technical team runs it daily	Online Store 2.0	Editability outweighs raw control
ERP-driven catalogue	Online Store 2.0 + strong field mapping	Metafields mirror ERP fields naturally
Bespoke, performance-critical design	Hand-coded from Dawn	Control and speed justify the maintenance cost
Fresh migration from another platform	Online Store 2.0, decided during migration	One clean chance to model data right

Checks we run when choosing between the two:

• Interaction test: Does the page need to branch logic, or just show rich data.
• Owner test: Who edits this in six months, and can they.
• Data test: Is there a structured source, and does it favour metafields.
• Design test: Is the design bespoke enough to justify custom code.
• Cost-over-time test: Which choice is cheaper to live with, not just to build.

Measuring Success: 30, 60, And 90 Day KPIs

A theme project is not done when it launches, it is done when the numbers move or you have learned why they did not. We instrument every build against the previous setup, because a store with no baseline is a store you cannot argue about. On Metalne Police the headline was an 18% conversion lift versus their old PDF-and-phone setup, and that is the kind of outcome we scope toward from day one.

Here is roughly how we phase measurement. The day-30 and day-60 figures below are Presta targets and estimates from how we run these projects, not measured client results; the only measured client result cited is the 18% conversion lift for Metalne Police, the 30% first-month revenue lift for Beberusha, and the 80% revenue lifts for Tehnodent and Cosmetica Labs, each attributed to that engagement.

Window	What we measure	What we are looking for
0 to 30 days	Conversion rate vs old setup, contact/phone volume, filter usage	Fewer support contacts, buyers self-serving on specs
30 to 60 days	Add-to-cart on spec-rich pages, bounce on product pages, merchant edit activity	Structured data earning its place; team editing without us
60 to 90 days	Revenue vs baseline, return rate on spec-driven products, repeat visits	Sustained lift, low returns from wrong-fit purchases

The return-rate metric matters more than people expect on spec-heavy catalogues. If you show load capacity and dimensions honestly at the point of decision, you get fewer wrong-fit purchases, and returns on heavy industrial goods are expensive to eat. That is a KPI we watch specifically because the whole thesis of the shelving build was answering the fit question before purchase.

On the fast-turnaround end, Beberusha’s 30% first-month revenue lift shows what measurement should look like when you are tuning an existing store: a clear before, a specific change to how the theme surfaced products, and a first-month number to check it against. We do not launch and hope.

Checks we run on measurement:

• Baseline capture: Do we have the old setup’s numbers before we change anything.
• Self-service signal: Is customer contact volume dropping as the store answers questions.
• Merchant activity: Is the client’s team actually editing, proving the handoff worked.
• Returns watch: On spec-driven goods, are wrong-fit returns falling.
• 90-day revenue: Is the lift holding beyond the launch bump.

Common Ways Both Approaches Break

Both paths fail in predictable ways, and knowing the failure modes is most of what experience buys you.

Hand-coded themes break through drift. Six months in, the store is three Shopify releases behind, a new feature the client wants requires the theme to be closer to current, and the custom code has quietly accumulated assumptions nobody documented. We have inherited these stores and the honest first step is often to figure out whether to keep patching or rebuild on Online Store 2.0. When we assess a store for this, the criteria are the same ones we describe in how to evaluate a Shopify migration agency, because a rebuild is a migration in disguise.

Online Store 2.0 builds break through metafield sprawl. A team adds fields ad hoc, uses the wrong types, stores numbers as text so they cannot be filtered, and two years later the “structured” data is as messy as free text ever was. The fix is discipline at step one of our framework, and it is why we push so hard to define the schema before anyone enters data. We also see theme-editor chaos, where too many blocks and no guardrails let a well-meaning merchant destroy a layout. We set block limits and sensible defaults so self-service does not become self-sabotage.

The failure that spans both is treating the theme as decoration. If you have not modelled what the customer needs to know, a beautiful theme on either architecture will still convert badly, because the buyer cannot answer their own question. The shelving store worked because we started from the question, not the layout. For the deeper platform reasoning behind why we keep landing on Shopify for these, our piece on Shopify’s explosive growth benefits and the 7 reasons to switch from WooCommerce to Shopify cover the ground, though we will happily build you a WooCommerce store when the ERP and licensing situation points that way, as it did for Tehnodent.

Checks we run to catch these failures early:

• Version distance: How far behind current is the theme, and can the client afford that.
• Type audit: Are numeric and filterable fields stored as proper types.
• Sprawl check: Is anyone adding metafields without a schema owner.
• Editor guardrails: Are block limits and defaults protecting the layout.
• Question test: Can a first-time visitor answer their own buying question unaided.

If you want to see how we present this kind of work, our Shopify agency portfolio examples for 2025 and our broader Shopify agency services guide show the range, from tweaks to full builds.

Final Verdict

Here is the head-to-head reduced to who wins each row, based on how these play out on real client work.

Criterion	Winner
Build speed	Online Store 2.0
Merchant self-service	Online Store 2.0
Structured product data	Online Store 2.0
Conditional/configurator logic	Hand-coded Liquid
Bespoke, performance-critical design	Hand-coded Liquid
Long-term maintenance cost	Online Store 2.0
Platform upgrade path	Online Store 2.0
ERP-driven technical catalogue	Online Store 2.0

For the most common case, a spec-heavy store run by a team that is not full of developers, we choose Online Store 2.0 with a disciplined metafield schema and tightly scoped custom sections. That is what we did for Metalne Police, and it is what earned the 18% conversion lift, because the architecture let us make specifications the interface without burying the client in code they cannot maintain. We choose hand-coded Liquid only when the interaction is genuinely conditional or the design and performance demands leave no other honest option, and even then we start from Dawn and diverge as little as we can get away with.

To close the loop on the shelving store: the thing we would do slightly differently now is spend even more of the early scope on the metafield schema, because every hour there saved us two in section work later, and it is the part clients underweight when they read a generic Shopify theme development tutorial and think the job is mostly design. If you are starting from scratch, prioritize modelling your product data before you touch a single template, because taxonomy and metafields are the load-bearing decisions. If you are auditing something that already exists, start by checking whether your filterable attributes are stored as proper structured data, because that is usually where a good-looking store is quietly losing sales.

Next Steps:

• List every attribute a customer needs to decide and to filter, and decide the metafield type for each before you design anything.
• Open your current store’s theme editor and check whether your own team can add a product and edit a layout without a developer.
• Capture your current conversion rate and product-page bounce now, so any theme change has a baseline to prove itself against.

Frequently Asked Questions

What are the steps to create a Shopify theme from scratch?

Honestly, most people who ask this should not start from scratch, they should start from Dawn, Shopify’s reference theme, and modify it. Building from a blank folder means you rebuild everything Dawn already gives you for free, including accessibility, responsiveness, and Online Store 2.0 support, and you diverge from the platform on day one. When we do go custom, we still base it on Dawn.

If you truly are building up from the base theme, the order that works is: model your product data as metafields first, define your collection and navigation structure around how customers shop, then build the layout and templates as sections that read that data, then wire up the theme editor settings so a merchant can control it. Presentation code comes last, once you know exactly what it needs to render.

The reason we insist on that sequence is scar tissue. We once designed a product page first and retrofitted the data afterward, and the data types did not match what the design assumed, so we rebuilt two sections and absorbed the overrun. Data first, layout second, every time.

Where can I find beginner-friendly Shopify theme development tutorials?

For fundamentals, Shopify’s own developer documentation and its Liquid reference are the most reliable and current sources, because they update with the platform. A random third-party Shopify theme development tutorial from a few years ago may still teach pre-Online Store 2.0 patterns, which will actively mislead you into building the old way. Check the date and check whether it uses sections everywhere and metafields.

The best learning project for a beginner is not a fantasy store, it is a small real catalogue with genuine attributes, because that forces you to confront metafields, filtering, and structured data, which is where the real skill lives. Building a homepage is easy. Building a product page that answers a buyer’s question from structured data is the thing worth learning.

If you are learning in order to run your own store rather than to become a developer, spend your time on the theme editor, metafields, and merchandising, not on Liquid internals. The people who get the most value from theme knowledge are the ones who learn what belongs in code versus what belongs in editable settings.

How long does it take to learn Shopify theme development?

To make useful, safe edits to a good Online Store 2.0 theme, most motivated people get comfortable within a few weeks of consistent practice. To build a full custom theme you would trust on a client’s store, our rough estimate from bringing people up is several months of real project work, because the hard part is not syntax, it is judgment about data modelling, handoff, and what not to customise.

The learning curve is much shorter if you never fight the platform. People who insist on hand-coding everything spend far longer, because they take on all the problems Online Store 2.0 already solved. People who learn to lean on sections and metafields become productive faster.

For a rough Presta estimate: producing a genuinely custom, maintainable theme takes our experienced team weeks, not days, and that is with years of practice behind it. Budget your own learning accordingly, and do not judge your progress by how much Liquid you can write, judge it by how little you needed to.

Is Online Store 2.0 always the right choice for a technical B2B catalogue?

Almost always, yes, and the ERP-integrated stores we have built are the evidence. When your source of truth is an ERP sending structured fields, metafields give each field a typed home and your theme becomes disciplined presentation. That is exactly how the dental equipment and the cosmetics builds worked, and both saw 80% revenue lifts with ERP integration underneath.

The exception is genuinely conditional configuration, where one selection constrains the next. There you use metafields for the data and write focused section code for the branching, which is a hybrid rather than pure Online Store 2.0. We do not build a full custom theme for it unless the configuration logic is genuinely the product.

So the honest answer is: default to Online Store 2.0 for technical catalogues, and treat full custom as the exception you have to justify, not the starting point.

How do metafields affect performance and page speed?

Metafields themselves are rendered server-side in Liquid, so a well-built spec block reading metafields is not inherently slow. What slows pages down is usually everything around them: too many apps injecting scripts, heavy images, and section code that loops inefficiently over large data sets. We watch loop complexity carefully on product pages with many variants and specs.

On spec-heavy catalogues we lazy-load below-the-fold sections and keep the spec block, which is above the fold and decision-critical, lean and server-rendered. The goal is that the numbers a buyer needs appear instantly, because that is the whole point of the design.

The bigger performance risk is a hand-coded theme that has drifted, where old, unoptimised custom code accumulates. Staying close to Dawn actually helps performance over time, because you inherit Shopify’s ongoing optimisations rather than freezing your store at whatever you built two years ago.

When does it make sense to bring in Presta rather than doing it ourselves?

Plainly: not everyone needs an agency. If you are running a small store with a conventional catalogue on a good Online Store 2.0 theme, you can and should learn to edit it yourself, and a tutorial plus the theme editor will take you a long way. We would rather tell you that than sell you a build you do not need.

The threshold where it becomes worth bringing us in is when the data or the integration is the hard part. If your product data lives in an ERP or messy spreadsheets, if your catalogue is technical enough that buyers need structured specs to purchase, or if you are migrating and want the data modelled properly during the move, that is where doing it yourself tends to produce a store that looks fine and converts poorly. That is our work: Shopify, WooCommerce, and Shopware builds, migrations, and the integrations behind them.

The other honest trigger is time and risk. If getting it wrong is expensive, high return rates on heavy goods, or a broken checkout during a migration, the cost of a rebuild dwarfs the cost of building it right once. When you hit that point, talk to our team and we will tell you candidly whether you need a tweak, like the Beberusha work, or a full build, like the shelving store.

Can I switch from a hand-coded theme to Online Store 2.0 later?

Yes, but treat it as a rebuild, not a toggle. Moving a hand-coded theme onto sections everywhere means re-expressing your templates as sections and blocks and, critically, moving whatever ad hoc data you stored into proper metafields. That data migration is usually the real work, and it is why we assess these the way we assess a platform migration.

We have inherited drifted custom themes and the decision is always the same calculation: is patching cheaper than rebuilding on a clean Online Store 2.0 base. Often, once a theme is several releases behind and the client wants new platform features, the rebuild pays for itself quickly because maintenance costs stop climbing.

If you suspect you are heading this way, do the schema-first work now even before you rebuild, because defining your metafields cleanly is progress you keep regardless of which theme architecture you land on.

Sources

• Shopify theme architecture documentation
• Shopify metafields and custom data documentation
• Shopify Liquid reference
• Shopify Dawn reference theme
• Shopify Online Store 2.0 announcement