Shopify and WooCommerce landing pages built in the theme

A landing template built as native sections inside the theme you already run ships around 12 KB of CSS and no builder runtime. The same page assembled in a drag-and-drop builder usually arrives carrying 300 to 600 KB of JavaScript before the first product image is even requested, and it stops being editable the day you change theme. We build the first kind, on Shopify Online Store 2.0 or a WooCommerce block theme, and we decline to build the second. What gets built: On Shopify, a page.landing.json template and the sections it references, each with a schema block so your team reorders, retitles and swaps imagery from the theme editor without opening a ticket with us. Offers and legal copy that differ by market sit in metafields rather than in duplicated pages. On WooCommerce, block patterns registered by a child theme, with type scale and colour drawn from theme.json so the page inherits the store's system instead of restating it. No page builder sits in the render path in either case. Where the cart path goes: Add to cart is where most landing templates quietly leak. Variant state stays in the section and posts to /cart/add.js, so choosing a size, a bundle or a service window does not reload the page and drop the click parameters your reporting depends on. On Woo the Store API at /wp-json/wc/store/v1/cart does the same job without a form round trip. Post-purchase tracking goes into a pixel extension: checkout.liquid ended for the information and payment steps in August 2024 and for the Thank You and Order Status pages in August 2025, so anyone handing you a script tag for order confirmation is describing a store that no longer exists. What you own at the end: A Git repository, not a theme export. Shopify work arrives as a branch wired to the GitHub integration, with sections readable by whoever you hire next. Woo work arrives as a versioned child theme. Handover is a recorded working session with the person who will edit the page after we leave, plus a short note naming which fields are safe to change and which will break the layout if they are. Not included: Checkout interface work beyond what checkout extensibility permits on your plan. Product data cleanup, taxonomy or merchandising rules. Photography, video and copy for products we have not been briefed on. App selection, or the subscription cost of anything we recommend. Platform migration between Shopify and WooCommerce, which is a separate job we would rather quote separately than smuggle into this one. Who this is not for: A campaign page with a three-week life. Build that as a standalone page and delete it afterwards; it has no business inside the theme. Also not for a store on a heavily customised theme two or more major versions behind, where new sections would land on top of patched Liquid nobody can safely read. We look first, and if that is the situation we say the theme needs handling before the template, rather than take the fee and inherit the mess. What we refuse: We refuse to ship a section without editor schema. A template your marketing team cannot change is a retainer disguised as an asset, and we would rather sell you the next piece of work on its merits. We refuse to install an app to make a section function when the section can carry its own markup. And we refuse to name a conversion figure for a template, because the offer, the price and the traffic decide that, and three of those are yours.