# shopifydevelopment.info — full text > The complete text of every guide in this language, so an answer engine can read the catalogue in one request. Nothing here is absent from the visible pages. ## Is Shopify Plus worth it? https://shopifydevelopment.info/guides/is-shopify-plus-worth-it Updated 2026-08-05 · Cost and hiring - Plus is an arithmetic decision, not a status decision. - Rate difference plus removable apps versus the price difference. - Use last quarter's real numbers, not a forecast. - Plan-gated checkout features make it a feasibility question. Shopify Plus is sold on capability and bought on feeling. The honest version is arithmetic: at what monthly volume do lower card rates plus the features you would otherwise buy exceed the price difference? For some stores the answer is clearly yes. For many it is not yet, and knowing which you are takes an afternoon. ### What you are actually buying | Lower card processing rates | Anyone above the crossover volume | | Deeper checkout extensibility | Stores with rules the standard checkout cannot express | | Multiple expansion stores | Genuinely separate brands or markets | | Higher API limits | Heavy integrations and frequent syncs | | Automation tooling | Operations with repetitive manual steps | | Named support | Teams who need an escalation path | ### The arithmetic Take your monthly card volume and multiply by the rate difference. Add the monthly cost of any app you could remove because Plus includes the capability. Compare that with the price difference. If the answer is negative, the upgrade is a preference, not an investment — and that is a legitimate choice as long as it is named honestly. Run the calculation with last quarter's real numbers, not with next year's forecast. Forecasts have a way of justifying whatever was already wanted. ### Reasons that are not reasons - "We are a serious brand now" — customers cannot tell which plan you are on. - "We might need it later" — upgrade later, when the need is real. - "Support will be better" — true, and rarely worth the difference on its own. - "An agency recommended it" — ask them to show the arithmetic. ### When it is clearly right High volume where the rate difference alone covers it, a checkout requirement that is gated to Plus, or several genuinely separate storefronts. In those cases the decision is easy and the calculation confirms it in minutes. Q: At what revenue does Plus make sense? A: There is no universal number. Calculate the crossover from your own card volume and rate difference. Q: Is checkout customisation Plus-only? A: Some extension points are gated by plan. If a requirement depends on one, that decides feasibility, not budget. Q: Can we downgrade later? A: Yes, though anything built on Plus-only features has to be unwound first. ## Keeping a Shopify store healthy after launch https://shopifydevelopment.info/guides/maintaining-a-shopify-store-after-launch Updated 2026-08-05 · Cost and hiring - Stores decay because the platform moves, not because code breaks. - Put updates, app reviews and API upgrades on a calendar. - Name a specific owner or the routine will not happen. - One quarterly half-day prevents most emergencies. A launched store feels finished. Six months later the theme is two versions behind, four apps are unused, the API version is expiring and nobody owns any of it. Maintenance is not a mysterious ongoing cost. It is a short, specific list on a calendar. ### The routine | Weekly | Check orders, failed payments and the error queue on integrations | | Monthly | Review the six core numbers; check for theme and app updates | | Quarterly | App review: uninstall anything without a named owner | | Quarterly | Performance check on a mid-range phone | | Twice a year | API version upgrade for any custom integration | | Yearly | Review markets, shipping rules and legal pages | ### What actually causes decay - Theme updates skipped because the customisations conflict. - API versions expiring on a custom app nobody remembers owning. - Apps accumulating until the storefront is slow and the bill is unexplained. - Product data drifting as new items are added by different people. - No owner — the most common root cause of all of the above. ### Name an owner or nothing happens Maintenance without a named person is maintenance that does not occur. It does not need to be a full-time role; it needs to be somebody's explicit responsibility with time allocated, whether internal or contracted. Write the owner's name in the handover document at launch. "The agency" is not a name, and neither is "whoever notices". ### The half-day that prevents most emergencies Once a quarter: update the theme deliberately, remove unused apps, re-test one order and one refund, check performance, and confirm every integration is running. Four half-days a year prevents nearly every incident we get called about. Q: How much maintenance does a Shopify store need? A: A few hours a month for a small store, more where integrations exist. Budget 15–25% of build cost per year. Q: What breaks most often? A: Custom integrations against expiring API versions, and themes that fell too far behind to update. Q: Can maintenance be outsourced? A: Yes, and it should be explicit — a named arrangement with a scope, not goodwill. ## Migrating to Shopify without losing traffic https://shopifydevelopment.info/guides/migrating-to-shopify-without-losing-traffic Updated 2026-08-05 · Cost and hiring - The redirect map is the migration; build it before anything else. - Verify every old URL resolves in one hop after launch. - Passwords cannot move — plan the reset communication. - Watch old URLs and organic traffic weekly for a month. Most migration horror stories are the same story: the products moved, the URLs did not, and three months of search traffic disappeared on launch day. Migration is mostly a mapping exercise. Do the mapping first and the rest is scheduling. ### The order that protects traffic - Export every URL that currently exists, with its traffic and its rankings. - Decide the destination for each one: a matching page, a parent page, or gone. - Build the redirect map as a file, reviewed before anything is built. - Migrate products, collections and content into the new structure. - Test redirects on staging with the real list, not a sample. - Launch, then re-crawl the old URL list to verify every redirect resolves in one hop. ### What breaks and what it costs | Unmapped URLs | Search traffic lost, sometimes permanently | | Chained redirects | Slow pages and diluted signals | | Changed product handles | Every external link and ad breaks | | Lost customer accounts | Password resets for your entire list | | Historical orders not migrated | Support and accounting lose their history | ### Data that is harder than it looks Customer passwords cannot be migrated between platforms, so plan the communication before launch rather than discovering it through a support queue. Historical orders may need to be imported for support and returns. Product reviews usually live in an app and need their own export and import. Write the migration runbook as a checklist with owners and a rollback point. Migrations fail at 2am because nobody wrote down the order of operations. ### After launch Watch the old URL list, indexation, and organic traffic weekly for the first month. A small dip that recovers in two to four weeks is normal. A dip that keeps falling means redirects are wrong, and it is much cheaper to find that in week one than in month three. Q: Will I lose rankings when migrating? A: A short dip is normal. A lasting loss almost always means unmapped or chained redirects. Q: Can customer passwords be moved? A: No. Plan a reset communication before launch rather than after. Q: How long does a migration take? A: Six to sixteen weeks for a real catalogue with integrations. Data cleanup, not the storefront, is the long pole. ## How to hire a Shopify developer or agency https://shopifydevelopment.info/guides/how-to-hire-shopify-developers Updated 2026-08-04 · Cost and hiring - Ask about constraints and refusals, not about portfolios. - "Shopify can do anything" is the answer that should worry you. - Insist on Git and code ownership from the start. - A small paid trial reveals more than a long interview. Portfolios show finished work under good conditions. What you need to know is how someone behaves when a requirement does not fit the platform, because that is the moment that decides your project. These are the questions we would ask, and the answers that should worry you. ### Questions worth asking | Tell me about a requirement you refused | A specific case, and the alternative they proposed | | How do you handle theme updates? | Additive changes, Git, diffing releases | | When would you tell a client not to use Shopify? | Concrete limits, not "it can do anything" | | How do you decide between an app and a custom build? | A cost and maintenance argument, not a preference | | What happens after launch? | A named maintenance arrangement, with a price | ### Answers that should worry you - "Shopify can do anything" — it cannot, and the person saying so will discover the limits on your budget. - No opinion about apps versus custom builds. - Portfolio work you cannot verify is live. - No version control, changes made directly in the admin editor. - No interest in your product data before quoting. ### Freelancer, agency or in-house A freelancer suits a defined build with a clear owner on your side. An agency suits work needing several skills at once — design, development, migration, integration — or when continuity matters more than price. In-house is justified when the store changes weekly and the changes are strategic. Whoever you hire, insist on the store being in a Git repository you own. It is the difference between changing supplier and starting again. ### A small paid trial beats a long interview Commission one well-defined piece of work — a section, a small integration — and see how it arrives: is it documented, additive, tested against a real catalogue? An afternoon of real work tells you more than three calls. Q: Freelancer or agency? A: Freelancer for a defined build with a clear owner internally; agency when you need several skills or continuity. Q: How do I check someone is any good? A: Ask what they refused to build and why, then commission a small paid piece of real work. Q: What should the contract include? A: Ownership of the code and the repository, a maintenance arrangement, and what happens at handover. ## What a Shopify build really costs https://shopifydevelopment.info/guides/shopify-development-cost Updated 2026-08-04 · Cost and hiring - Build cost is driven by data quality and integrations, not design. - Ranges are wide because scope is usually underspecified. - Budget 15–25% of build cost per year for maintenance. - Compare quotes by comparing their assumptions first. Quotes for Shopify work vary by an order of magnitude, which tells you the question is underspecified rather than that someone is overcharging. The variation comes from a small number of factors, and once you can name them you can read a quote properly — and predict the cost that arrives after launch. ### Typical build ranges | Standard theme, light customisation | $2,000 – $10,000 | Catalogue size and data quality | | Serious theme build or migration | $15,000 – $50,000 | Real data, redirects, integrations | | Custom app or integration | From $10,000 | Number of systems and their APIs | | Headless storefront | Higher, plus ongoing team | Everything you now own | ### What actually moves the number - Product data quality — the single largest hidden variable in any quote. - Number of integrations, and whether their APIs are documented. - How far the theme must move from standard. - Number of markets, each with its own tax and content work. - Whether anyone has written down what makes an order correct. ### The bill after launch Plan, payment processing, apps and maintenance continue forever. Budget roughly 15–25% of build cost per year for maintenance — not because the code rots, but because the platform moves underneath it and somebody has to keep up. A store with no maintenance budget does not stay still; it quietly falls behind until a rebuild is the only option. ### How to compare two quotes Ask both to state their assumptions about product data, integrations and markets. The cheaper quote is usually cheaper because it assumed clean data and no integrations. Once assumptions are equal, the numbers converge remarkably fast. Q: Why do quotes vary so much? A: Because scope is usually underspecified. Data quality and integrations move the number more than design does. Q: Is a fixed price realistic? A: For a well-defined theme build, yes. For a migration with unknown data quality, a phased approach protects both sides. Q: What should I budget for year two? A: Plan and processing, app subscriptions, and 15–25% of build cost for maintenance. ## Selling in several markets without doubling the work https://shopifydevelopment.info/guides/selling-in-multiple-markets-on-shopify Updated 2026-08-04 · Conversion and growth - Currency is trivial; tax, duty, returns and content are the work. - Quote the delivered price or say clearly that duty is payable. - Give each language its own URLs and proper hreflang. - Open one market properly before opening a second. Adding a market looks like a settings change and behaves like a small project. The store will happily show prices in another currency; whether the order is correct, deliverable and returnable is a different question. Here is what a second market actually requires, in the order it bites. ### What a new market really needs | Currency and pricing | Low | Nobody | | Tax rules for the destination | Medium | Most first attempts | | Delivered cost including duty | Medium | Almost everyone | | Translated content | High if done properly | Teams who use auto-translation | | Returns address in market | Operational | Everyone, until the first return | | Support in the language | Ongoing | Everyone | ### Duty and the delivered price A customer who pays at checkout and is then asked for duty on delivery will refuse the parcel and request a refund. Either quote the delivered price including duty or state clearly that duty is payable on arrival. Silence is the option that generates refunds and complaints. Model the fully delivered cost for your three largest destinations before enabling them. If the honest total makes the product uncompetitive, the market is not open to you yet. ### Content, not just currency - Machine-translated product copy reads as machine-translated and converts accordingly. - Each language needs its own URLs and correct hreflang, or your markets compete in search. - Size, measurement and address formats are localisation, not translation. - Legal pages differ by market — returns rights are not universal. - Support has to answer in the language you sold in. ### A sensible sequence Open one market properly rather than five approximately. Get tax, delivered price, returns and content right for a single country, learn what breaks, then repeat. Five half-open markets produce support tickets in five languages and revenue in none. Q: Is currency conversion enough to sell abroad? A: To take an order, yes. To take a correct, deliverable, returnable order, no. Q: Do I need separate URLs per language? A: Yes, with correct hreflang. Shared URLs with a language switcher hide your content from search. Q: How many markets should we open at once? A: One. Learn the failure modes cheaply before multiplying them. ## Analytics you can actually trust https://shopifydevelopment.info/guides/shopify-analytics-you-can-trust Updated 2026-08-04 · Conversion and growth - Shopify is the source of truth for money; nothing else is. - Analytics and ad platforms count different things and always will. - Never sum conversions claimed by different ad platforms. - Report six numbers consistently rather than forty occasionally. Every store reaches the week where three dashboards show three different revenue figures and someone is asked to explain it. The explanation is always the same, and it is not a bug. Each system counts something different, attributes differently, and loses different events. Knowing which to believe for which question ends the argument permanently. ### Why the numbers differ | Shopify | Orders actually placed and paid | Nothing — this is the money | | Web analytics | Sessions and events in the browser | Blocked scripts, consent refusals | | Ad platforms | Conversions attributed to their own clicks | Nothing they can claim; they double-count each other | | Email tools | Clicks and attributed orders in their window | Everything outside the window | ### Pick one source per question - Revenue, orders, refunds: Shopify. Always. It is the system that took the money. - Traffic and on-site behaviour: your analytics tool, understood as directional. - Channel performance: ad platforms, compared against themselves over time, never summed. - Customer lifetime value: your own calculation from Shopify order data. ### Attribution never sums to 100% If you add up the conversions each ad platform claims, you will exceed your actual order count. Every platform claims a touch it saw. This is expected behaviour, not fraud, and the correct response is to stop adding them together — use each platform's numbers only to compare that platform against its own past. Report one revenue number, from Shopify, in every meeting. Channel numbers go in a separate section marked as directional. ### A reporting set worth keeping Orders, revenue, average order value, conversion rate, repeat purchase rate, and refund rate — monthly, from Shopify, with a note explaining anything unusual. Six numbers reported consistently for a year are worth more than forty reported once. Q: Which revenue number is correct? A: Shopify's. It is the system that processed the payment; everything else is an estimate of it. Q: Why do ad platforms overstate results? A: Each claims conversions it can associate with its own clicks, and several can claim the same order. Q: Do I need a separate analytics tool? A: For on-site behaviour, yes, it helps. For money questions, no — that is Shopify's job. ## Conversion fixes that actually move the number https://shopifydevelopment.info/guides/shopify-conversion-rate-optimisation Updated 2026-08-04 · Conversion and growth - Fix the biggest funnel drop, not a list of small tweaks. - Surprise shipping cost is the single largest abandonment cause. - Speed on mobile is a conversion feature, not a technical one. - Below a few hundred orders a month, skip A/B tests and fix known problems. Conversion advice tends to arrive as a list of tweaks. Most of them are real but small, and running them in a random order means spending months for a rounding error. Work the funnel instead: find the step with the biggest drop, fix its known cause, measure, repeat. ### The usual order of magnitude | Show shipping cost earlier | Large | Low | | Speed up the product page on mobile | Large | Medium | | Remove forced account creation | Large | Low | | Better product images and real photos | Moderate | Medium | | Clear returns policy near the buy button | Moderate | Low | | Button and copy tweaks | Small | Low | ### Find the leak before fixing anything - Count sessions reaching product page, cart, checkout start, payment, and order. - Find the biggest percentage drop between two adjacent steps. - Ask what the customer learns at that step that they did not know before. - Fix that specific thing. - Re-measure over a full week — traffic mix varies by day. ### Why shipping cost dominates The largest single cause of abandonment in most stores is a shipping cost that appears for the first time at checkout. The customer has not changed their mind about your product; they have learned a price they were not told. Showing it on the product page costs you nothing and removes the surprise. If free shipping over a threshold is viable, say the threshold on the product page. Half the effect is knowing, not paying. ### Testing honestly Most Shopify stores do not have the traffic for meaningful A/B tests on small changes. Below a few hundred orders a month, prefer obvious fixes and before-and-after measurement over tests you cannot power. Pretending a test was conclusive is worse than not testing. Q: What is a good conversion rate? A: It varies enormously by category and price point. Compare against your own trend, not against a published average. Q: Should I run A/B tests? A: Only with enough traffic to reach significance in a reasonable time. Otherwise fix known problems and measure the trend. Q: Do trust badges help? A: Less than a clear returns policy, a visible shipping cost and a fast page. ## The SEO work Shopify does not do for you https://shopifydevelopment.info/guides/shopify-seo-fundamentals Updated 2026-08-04 · Conversion and growth - Shopify covers technical SEO basics; architecture and content are yours. - One deliberate page per search intent beats fifty thin collections. - Decide explicitly which filtered pages may be indexed. - Original product copy outranks and outconverts manufacturer text. Shopify handles a good deal of technical SEO by default: sane markup, canonical tags, sitemaps, fast hosting. That is the floor, and it is a decent one. What it cannot do is decide how your catalogue is organised or write anything worth ranking. Those are the two things that actually move traffic. ### What the platform gives you | Sitemaps and canonical tags | Which pages should exist at all | | Fast, reliable hosting | Page speed after your images and apps | | Basic product markup | Descriptions worth reading | | HTTPS and clean URLs | Collection architecture and internal linking | | Redirect tool | Actually mapping redirects during a migration | ### The quirks worth knowing - Products are reachable both directly and within a collection path; canonicals handle it, but internal links should be consistent. - Collection filters can generate many thin, near-duplicate pages — decide which are indexable. - The blog is functional but limited; treat it as a place for genuinely useful content, not a content platform. - Pagination on large collections needs thought, both for crawling and for customers. - Multi-market setups need hreflang done properly or markets compete with each other. ### Collection architecture is the real lever Most Shopify SEO gains come from having the right collection pages: one page per thing people actually search for, with a description that answers the question, and internal links from related products. A store with fifty thin auto-generated collections ranks worse than one with twelve deliberate ones. Write down the searches you want to rank for, then check that exactly one page targets each. Duplicate targeting is the most common self-inflicted SEO problem. ### Product descriptions do work Manufacturer copy appears on every competitor's site. Two original paragraphs answering the questions your support team actually receives will outrank it, and will convert better while they do. Q: Does Shopify handle SEO automatically? A: It handles the technical floor. Architecture, content and internal linking — the parts that rank — are yours. Q: Should collection filters be indexable? A: Only the ones matching real searches. Leave the rest out of the index rather than generating thin pages. Q: Is the Shopify blog good enough? A: For a handful of genuinely useful articles, yes. For a serious content operation, most teams run a separate system. ## Shopify theme speed on real phones https://shopifydevelopment.info/guides/shopify-theme-speed Updated 2026-08-04 · Conversion and growth - Images and third-party scripts cause most Shopify slowness. - Measure on a mid-range phone, not on your laptop. - Fix in order: images, scripts, hero, fonts, then code. - Bring per-app numbers to the conversation about removing apps. Speed work on Shopify has a predictable shape: teams optimise Liquid, argue about the theme, and leave a hero image at four times the size it renders and eleven third-party scripts loading before the page paints. Measure first, then fix in the order that pays. ### Where the time actually goes | Oversized or unoptimised images | Large | Easy | | Third-party and app scripts | Large | Medium — political, not technical | | Web fonts | Moderate | Easy | | Heavy sliders and video hero sections | Moderate | Easy, if you can win the argument | | Liquid rendering | Small | Medium | ### The order to work in - Measure on a mid-range phone on a real connection, not on your laptop. - Fix images: correct dimensions, modern format, lazy-load anything below the fold. - Audit scripts: remove apps nobody uses; defer everything that is not needed to paint. - Cut the hero: one image beats an autoplaying video carousel on every metric that matters. - Subset and preload fonts, or use system fonts. - Only then look at the theme code. ### Measure the thing customers feel Largest contentful paint on the product page over a mobile connection is the number that correlates with revenue. Synthetic scores are useful for spotting regressions and terrible as goals — a store can score well and still feel slow to a customer on a train. Record a baseline before any change and after each one. Without a baseline, speed work becomes an argument about opinions. ### The app conversation Most speed problems are somebody's favourite app. Bring numbers: this app costs 400ms on every product page and is used by two people. That conversation goes better than "the site is slow" and it is the one that produces real gains. Q: Does the theme choice matter for speed? A: Less than images and scripts. A well-built theme helps, but it cannot outrun eleven third-party scripts. Q: Is a perfect score worth chasing? A: No. Chase the product page paint time on a mid-range phone; that is what customers experience. Q: Do apps really cost that much? A: Storefront-facing ones do. Measure each one by disabling it and re-testing — the numbers usually settle the debate. ## Checkout extensibility: what you can and cannot change https://shopifydevelopment.info/guides/shopify-checkout-extensibility Updated 2026-08-04 · Apps and integrations - Checkout is extensible at defined points, not replaceable. - Payment handling and the order model stay with the platform. - Some extension points are plan-gated — check during scoping. - Enforce rules with validations rather than with messages. Checkout is the part of Shopify you most want to change and the part you control least. That is deliberate: it is also the part Shopify has optimised hardest and made responsible for payment compliance. Modern checkout extensibility gives you defined extension points. This is what they cover and what they do not. ### Where you can extend | UI extensions at defined positions | Custom fields, delivery instructions, gift options | | Validation rules | Blocking an order that violates a business rule | | Discount logic | Custom promotion behaviour beyond the built-in types | | Delivery customisation | Reordering, renaming or hiding shipping options | | Post-purchase page | Upsells and additional information after payment | | Branding controls | Colours, fonts and layout within the given structure | ### What remains Shopify's - The order of the checkout steps and the overall structure. - Payment handling and PCI scope — you do not touch card data. - The order object model that everything downstream reads. - The fraud and risk layer. - Anything requiring arbitrary server-side logic in the middle of the flow. ### Plan-gated, and that matters early Some extensibility is available only on higher plans. If a requirement depends on it, the plan decision is a feasibility decision, not a budgeting one — and it belongs in the first week, not the last. Check plan gating for every checkout requirement during scoping. It is the most common source of "we assumed we could" late in a project. ### A pragmatic approach Express business rules as validations and delivery customisations rather than as UI. A rule enforced at checkout is reliable; a rule communicated by a message someone might not read is not. And keep custom fields to what you will genuinely act on — every additional field costs conversion. Q: Can I build a completely custom checkout? A: No, not on standard plans. You extend defined points; the structure and payment handling remain Shopify's. Q: Are checkout scripts still the way to do this? A: No. The modern approach is checkout extensions and functions; older script-based customisation is being retired. Q: How much can I add before conversion suffers? A: Less than you would like. Every field and message is friction; add only what changes an outcome. ## Connecting Shopify to an ERP or fulfilment system https://shopifydevelopment.info/guides/connecting-shopify-to-erp-and-fulfilment Updated 2026-08-04 · Apps and integrations - Write the field-ownership table before any code. - One owner per field and one direction per sync. - Give stock a single authoritative system, usually the warehouse. - Log everything with stable identifiers and a visible failure queue. Integration projects fail on ownership, not on protocol. Once two systems both believe they own the stock number, every subsequent bug is a symptom of that one unmade decision. So the first deliverable is not code. It is a table. ### The ownership table you write first | Product master data | Usually ERP | ERP → Shopify | | Price | Usually ERP | ERP → Shopify | | Stock level | One system, never both | Warehouse → Shopify | | Orders | Shopify | Shopify → ERP | | Fulfilment status and tracking | Warehouse | Warehouse → Shopify | | Customer record | Depends; decide explicitly | One direction only | ### The rules that keep it sane - One owner per field, and the other system never writes it. - Sync in one direction per field. Bidirectional sync is where the loops live. - Use a stable external identifier — SKU, not internal database IDs. - Make everything idempotent so a replay is harmless. - Log every message with its identifier so a disputed order can be traced end to end. ### Stock is the hard part Stock is the field everyone wants to write and nobody wants to own. Pick the system closest to the physical goods, usually the warehouse, and let it be authoritative. Shopify then reflects that number rather than negotiating with it. Oversells are almost always a symptom of two writers, not of sync latency. Fix ownership before tuning frequency. ### Plan for the boring failures The warehouse goes offline for an hour; the ERP rejects a malformed address; a product exists in one system and not the other. None of these are exotic, and all of them need a defined behaviour and a place where a human can see the queue. Q: Real-time or batch sync? A: Orders promptly, stock frequently, product data on a schedule. Real-time everything costs more and improves little. Q: Should we use a middleware platform? A: For several systems, yes — it centralises retries, logs and mapping. For one integration it is often more moving parts than value. Q: Who fixes a stuck message at 2am? A: Decide before launch. An integration without an owner and a visible queue becomes silent data loss. ## The Admin API and webhooks in practice https://shopifydevelopment.info/guides/shopify-admin-api-and-webhooks Updated 2026-08-04 · Apps and integrations - Read with the API, react with webhooks, reconcile on a schedule. - Verify signatures and make every handler idempotent. - Design for rate limits instead of retrying past them. - Diary API version upgrades before they expire. Integrations against Shopify are mostly two mechanisms: the Admin API, which you call to read and write, and webhooks, which call you when something happens. Both are straightforward. What separates a reliable integration from a flaky one is how you handle the cases where they misbehave — and they will. ### The two mechanisms | Direction | You call Shopify | Shopify calls you | | Good for | Reading state, writing changes, backfills | Reacting to events promptly | | Failure mode | Rate limits, version changes | Duplicates, out-of-order delivery, missed events | | Must handle | Retries and pagination | Idempotency and verification | ### Rules that make integrations reliable - Verify every webhook signature before trusting the payload. Unverified endpoints are an open door. - Make every handler idempotent — the same event will arrive twice eventually. - Do not assume order. A cancellation can arrive before the creation you were waiting for. - Return quickly and process asynchronously; slow endpoints get retried and then disabled. - Reconcile daily against the API. Webhooks miss events; a nightly sweep catches what slipped. ### Rate limits are a design input Shopify meters API access. That is not an obstacle to work around with retries; it is a constraint to design for. Batch reads, request only the fields you need, and use bulk operations for backfills instead of walking every product one call at a time. If your integration only works when nothing else is running, it does not work. Test it while an import is in progress. ### Versioning API versions are dated and expire. Put the upgrade in the calendar rather than discovering it through a failure. A small integration takes an hour to move forward; one that has skipped four versions takes a week. Q: Webhooks or polling? A: Webhooks for promptness, a periodic reconciliation for correctness. Most reliable integrations use both. Q: How do I stop duplicate processing? A: Store the event identifier and ignore repeats. Idempotency is the single most valuable habit here. Q: What breaks first at scale? A: Rate limits, usually during a backfill that walks records one at a time instead of using bulk operations. ## When to build a custom Shopify app https://shopifydevelopment.info/guides/when-to-build-a-custom-shopify-app Updated 2026-08-04 · Apps and integrations - Install for standardised, boring jobs someone else will maintain. - Build when the logic encodes how you specifically sell. - A one-verb private app beats a public app with unused settings. - Check metafields, metaobjects and Flow before doing either. The choice is usually framed as build versus buy, which hides the option most teams should take: a small private app that does one job well, rather than a public app with a settings screen you will never open. Here is how we decide, in the order the questions matter. ### Install when - The job is standardised: reviews, address validation, accounting export, basic subscriptions. - Many merchants need exactly what you need, so the app is maintained by someone else's revenue. - The pricing is flat or grows slowly with your volume. - You would otherwise be maintaining a commodity. ### Build when | The logic is specific to how you sell | No vendor will maintain your rules for you | | Data must reach a system nobody else uses | Integrations are the classic private-app job | | Per-order pricing at your volume | Buying becomes more expensive than a small build | | You need one feature from a large app | You are paying for a suite to use a switch | ### The middle path most teams miss A private app doing one job against the Admin API is often a few hundred lines and a small server. It has no settings screen, no onboarding, no billing, and no listing requirements — because it has exactly one user, you. Scope a private app to one verb. "Sync orders to the warehouse" is a private app. "Manage fulfilment" is a product. ### Before either, check what already exists Metafields, metaobjects and Shopify Flow cover a surprising amount of what teams reach for apps to do — conditional tagging, notifications, simple automations, structured product data. It costs an hour to check and regularly saves a subscription. Q: Is a private app hard to maintain? A: Less than expected if it does one thing. The maintenance cost comes from scope, not from the fact of owning it. Q: Do custom apps need review by Shopify? A: Public listings do. An app used only by your own store does not go through the listing process. Q: What about API version changes? A: Plan for periodic upgrades. That is the real ongoing cost of owning an integration, and it is manageable when the app is small. ## Choosing Shopify apps without accumulating them https://shopifydevelopment.info/guides/choosing-shopify-apps-without-bloat Updated 2026-08-04 · Apps and integrations - Apps accumulate one reasonable decision at a time. - Check metafields and Flow before installing anything. - Review the app list quarterly and uninstall the unowned. - Clean up leftover scripts and metafields after removal. No store sets out to install fifteen apps. It happens one justified decision at a time, and the aggregate is never reviewed because no single decision was wrong. Two costs accumulate quietly: money, and the scripts every app leaves on your storefront. ### The two bills you are signing | Subscription | Monthly, per app | Finance, eventually | | Storefront scripts | Slower pages on real phones | Customers, immediately | | Data sprawl | The same field in three places | Whoever debugs it | | Lock-in | Metafields and settings owned by the app | You, at removal time | ### Questions before installing anything - What exactly stops happening if we do not install this? - Do metafields, metaobjects or Shopify Flow already do it? - Does it add anything to the storefront, and can that be measured? - What happens to our data if we uninstall in a year? - Who reviews this in three months? ### Run a quarterly review Put a recurring hour in the calendar. List every installed app with its monthly cost and one sentence saying who uses it. Anything nobody can name a use for gets uninstalled that day, and the store gets measurably faster and cheaper without a project. Take a performance measurement before and after the review. The number is usually persuasive enough to keep the habit. ### Uninstalling properly Removing an app rarely removes its leftovers: script tags, metafields, webhooks and theme snippets can survive. After uninstalling, check the theme for orphaned code and the storefront for scripts that still load. This is the step that turns app removal into an actual improvement. Q: How many apps is too many? A: There is no number. The test is whether each one has a named owner and a use somebody can describe. Q: Do apps really slow the store down? A: Storefront-facing ones do, in proportion to what they load. Admin-only apps do not touch page weight. Q: Is one expensive app better than three cheap ones? A: Often, yes — fewer integrations, fewer scripts, one vendor relationship. ## Headless Shopify and Hydrogen: when it is justified https://shopifydevelopment.info/guides/headless-shopify-and-hydrogen Updated 2026-08-04 · Themes and storefront - Headless trades platform convenience for total control and permanent maintenance. - Justify it with integration or team reality, not with dissatisfaction about a theme. - Measure the existing theme before blaming the theme layer. - Budget for rebuilding the merchant editing experience you lose. Headless commerce means running your own storefront against Shopify's APIs instead of using a Liquid theme. Hydrogen is Shopify's framework for doing that. The technology works. The question is whether the store you are building needs it, because the cost is not the build — it is the decade of maintenance that follows. ### What you gain and what you take on | Storefront control | Within theme structure | Total | | Hosting | Shopify | Yours to run | | Time to launch | Weeks | Months | | Platform updates | Mostly automatic | Your dependency upgrades | | Theme editor for merchants | Full | Whatever you build | | Team needed | Shopify developer | Front-end team, ongoing | ### Good reasons to go headless - The storefront must integrate deeply with a non-Shopify experience — a configurator, a booking system, an existing app. - Content and commerce are equally important and live in a separate system already. - You have a front-end team who will still be here in three years. - Performance requirements the theme layer genuinely cannot meet, measured rather than assumed. ### Bad reasons "Themes are limiting" usually means the theme was chosen badly or customised into a corner. "Headless is faster" is true only if you build it well; a poorly built headless storefront is slower than a good theme, and there is nobody but you to fix it. Measure the current theme before concluding the theme is the problem. In most audits the problem is apps and images, and both survive a headless rebuild. ### The part people forget You lose the theme editor. Merchants who could reorder a page now file a ticket. Rebuilding a merchant editing experience is real work, and skipping it moves the cost from your team to theirs, permanently. Q: Is Hydrogen required for headless? A: No, but it is the best-supported path and removes a lot of undifferentiated work if you are going headless anyway. Q: Does headless improve SEO? A: Only through speed and structure you would have to build correctly. It also introduces ways to get rendering wrong that a theme cannot. Q: Can we go headless later? A: Yes. Keeping product data clean and content in metaobjects makes that migration much cheaper. ## Online Store 2.0: sections, blocks and metafields in practice https://shopifydevelopment.info/guides/online-store-2-sections-and-metafields Updated 2026-08-04 · Themes and storefront - Sections and blocks let merchants compose pages without developers. - Metafields and metaobjects are your structured data layer — design them. - Ship few, well-named sections rather than many near-duplicates. - Document metafields or they get deleted by someone later. Online Store 2.0 turned the theme from a set of fixed templates into a composable system: sections on every page, blocks inside them, and structured metafields to hold your own data. The features are widely known. What is less common is building as though they exist, rather than bolting them onto an older approach. ### The three pieces and what each is for | Sections | Reorderable modules on any template | Merchants, in the theme editor | | Blocks | Repeatable items inside a section | Merchants | | Metafields | Structured, typed data on products and other objects | You define, merchants fill | | Metaobjects | Your own content types, reusable across pages | You define, merchants fill | ### How this changes theme design The old instinct is to hard-code a product page and give merchants a handful of settings. The 2.0 instinct is to ship a small set of well-made sections and let the merchant compose pages. Fewer bespoke templates, more reusable parts — and far fewer developer requests for layout changes six months later. Every layout tweak a merchant can make themselves is a support ticket you never receive. ### Metafields deserve a data model - Define types deliberately: a size chart is a metaobject, not a rich-text blob. - Name them for what they mean, not where they appear on the page. - Decide which are merchandising data and which are content — they have different owners. - Fill them at import time, not manually, if your catalogue is more than small. - Document them; an undocumented metafield is discovered a year later by someone who deletes it. ### A good starting structure One product template with sections for gallery, buy box, description, specifications, and cross-sells. Specifications read from metafields. Cross-sells configurable per collection. That structure covers most catalogues without a single bespoke template. Q: Do I need to migrate an older theme to 2.0? A: Not urgently, but new builds should assume it. The editing experience and the maintenance cost are both meaningfully better. Q: Metafields or a separate content system? A: Metafields for anything attached to a product or collection. A separate system when the content has its own life and audience. Q: How many sections is too many? A: When merchants cannot tell two apart. Fewer, better-named sections beat a long list of near-duplicates. ## Liquid basics for developers coming from elsewhere https://shopifydevelopment.info/guides/liquid-basics-for-developers Updated 2026-08-04 · Themes and storefront - Liquid renders; it is not an application language. - Metafields and metaobjects are where your own data belongs. - Loops and per-request computation are the usual performance traps. - Split the work: data in metafields, behaviour in apps, formatting in Liquid. If you have written templates before, Liquid will take an afternoon. What takes longer is accepting what it will not let you do, because those limits are deliberate and they shape how Shopify themes are built. This is the orientation we give developers joining a Shopify project from any other stack. ### The mental model Liquid is a rendering language, not an application language. It has objects handed to it by Shopify, filters to format them, and tags for control flow. There is no database access, no arbitrary computation of consequence, and no way to reach outside the objects you were given. If you need something the object does not contain, the answer is a metafield, an app, or a different page. Every hour spent trying to make Liquid behave like a general-purpose language is an hour that should have been spent on the data model. ### What you will use constantly | Objects | product, collection, cart, customer, shop — the data of the page | | Filters | Formatting: money, date, image_url, escape | | Tags | Control flow: if, for, assign, render | | Sections and blocks | Merchant-editable structure in the theme editor | | Metafields | Your own structured data attached to Shopify objects | ### Common traps - Loops over large collections render slowly; paginate rather than filtering in Liquid. - Anything you compute per request is computed on every request — cache-friendly output matters. - render receives an isolated scope; include is deprecated and behaves differently. - Money is stored in cents; use the money filters rather than doing arithmetic by hand. - Customer-specific content prevents naive full-page caching, which is a performance decision as well as a correctness one. ### Where to put logic instead Data shaping belongs in metafields and metaobjects, defined once and read cheaply. Behaviour belongs in an app or in the browser. Liquid should mostly read and format. Themes that follow that split stay fast and comprehensible. Q: Is Liquid hard to learn? A: No — a competent developer is productive in a day. Learning what Shopify will not let you do takes longer. Q: Can I query data in Liquid? A: Only what the page object graph gives you, plus metafields. There is no arbitrary querying. Q: Should logic live in Liquid or JavaScript? A: Presentation logic in Liquid, interaction in JavaScript, business rules in an app or in your data model. ## Theme customisation that survives updates https://shopifydevelopment.info/guides/shopify-theme-customisation-that-survives-updates Updated 2026-08-04 · Themes and storefront - Add sections; do not edit core templates. - Keep the theme in Git and document every customisation. - Diff vendor releases before updating rather than skipping updates. - When your diff exceeds the theme, rebuild instead of forking. Every Shopify project reaches the moment where the theme does not quite do something. What happens next decides how expensive the store is for the rest of its life. There are good places to put a change and bad ones, and the difference is entirely about what happens when the theme updates. ### Where to put a change, best to worst | Theme settings | Always | Anything the theme already exposes | | A new section or block | Usually | New layout or content module | | App block | Usually | Functionality from an app | | A copied section, renamed | Mostly | You need a variant of an existing section | | Editing a core template | Rarely | Last resort, documented | | Scattered edits across files | Never | Never | ### The rule that keeps a theme maintainable Add, do not edit. A new section you own will still be there after an update. A modified core template will conflict with every release until somebody gives up and stops updating — which is how stores end up three years behind on platform features. Keep a CUSTOMISATIONS.md in the theme repository listing every file you touched and why. Future-you will not remember, and neither will the next developer. ### Practical habits - Work in a Git repository with the theme, not only in the admin editor. - Use a development theme for changes and publish deliberately. - Prefix your own sections and snippets so they are obvious in a file list. - Put custom CSS in one file, not sprinkled through templates. - Before an update, diff the vendor release against your copy and review the conflicts. ### When to stop customising and rebuild When the diff against the vendor theme is longer than the theme itself, you are maintaining a fork without admitting it. At that point a purpose-built theme is cheaper and honest about what you own. Q: Can I edit theme files directly in the admin? A: You can, and for a one-line fix it is fine. Anything larger belongs in version control where it can be reviewed and reverted. Q: How do I update a customised theme? A: Take the vendor release, diff it against your version, and reapply your changes deliberately. This is only feasible if your changes are additive and documented. Q: Are app blocks safe? A: Safer than editing templates, yes. Their risk is the app disappearing, not the theme update. ## Choosing a Shopify theme you can live with https://shopifydevelopment.info/guides/choosing-a-shopify-theme Updated 2026-08-04 · Themes and storefront - Judge update history and structure before appearance. - Shopify's own themes track platform changes first and cost nothing. - A heavily modified paid theme is the worst of both worlds. - Test with your real catalogue, not the demo data. Theme selection is usually done on appearance, which is the one attribute you can change later. The attributes you cannot change later — how the theme is structured, and whether the vendor still ships updates — get almost no attention. Here is what to look at instead, in the order that matters. ### What to judge, in order - Update history: when did the vendor last ship, and how often? - Structure: is customisation done through sections and settings, or through editing templates? - Closeness to your catalogue: does the product page already handle your variant count and media? - Performance out of the box: what does it load before anything is customised? - Support: is there a human who answers, and a changelog you can read? ### Free, paid or custom | Tracks platform changes | Yes, first | Depends on vendor | You do | | Cost | Free | One-off | Project | | Risk | Lowest | Vendor abandonment | Yours entirely | | Right when | Most stores | A close match exists | Merchandising truly does not fit | ### The trap in the middle A heavily modified paid theme is the worst of both worlds: not updatable, because your changes conflict with every release, and not really yours, because you did not design its structure. If you are going to change that much, either stay close to standard or commission a theme properly. Count the customisations before you start. Past roughly a dozen structural changes, a purpose-built theme is usually cheaper over two years. ### A short evaluation you can run in an hour Install the theme on a development store, import fifty real products with your worst-case variants, and put your longest product title and your least flattering image in it. Most themes look excellent with three products and studio photography; you need to know how this one behaves with yours. Q: Are Shopify's own themes good enough? A: For most stores, yes — and they are the safest base because they follow platform changes first. Q: How do I check a paid theme is maintained? A: Read its changelog and update dates. A theme with no release in a year is a liability whatever it looks like. Q: Can I change theme later? A: Yes, and it costs the customisation work again. Content and products carry over; layout decisions do not. ## When Shopify is the wrong choice https://shopifydevelopment.info/guides/when-shopify-is-the-wrong-choice Updated 2026-08-04 · Shopify basics - Most stores fit; the ones that do not fail expensively and late. - Arbitrary per-customer pricing and owning checkout are hard limits. - Configurable products do not fit a product-and-variant model. - Test your three hardest rules against the platform before building. We build on Shopify for a living, which is exactly why this page exists. The expensive projects are not the ones that chose a different platform; they are the ones that chose Shopify for a business it could not express and discovered it in month four. Here are the five patterns that should stop you, and the honest test for each. ### The five deal-breakers | Customer-specific pricing logic | Checkout cannot express arbitrary per-customer rules | | Owning the payment experience | Checkout is Shopify's; you extend, you do not replace | | Configurable products | Product and variant structure cannot represent a configurator | | Very high order volume with simple rules | Per-order fees become a material cost line | | Regulated flows needing custom steps | Required steps may not fit inside the checkout you are given | ### The test that settles it in an afternoon Write your three hardest business rules as plain sentences. Then try to express each one using only products, variants, metafields, discounts and the checkout as they ship. If one of them needs the checkout to do something it does not do, you have found your answer before spending anything. Do this with someone who has built on the platform. The failure mode is a confident "we can probably do that with an app" from someone who has not tried. ### Cases that look like deal-breakers but are not - B2B pricing — often solvable with the B2B features on higher plans, if the rules are tiered rather than arbitrary. - Subscriptions — well served by mature apps; the work is in dunning and support, not in the platform. - Multiple markets — supported, though tax and content per market is real work either way. - Heavy content marketing — the blog is weak, but a separate content system alongside the store is a normal pattern. ### If you are on the line Build the narrow version on Shopify, sell for a quarter, and let real orders tell you whether the constraint you feared actually binds. That is cheaper than a custom build commissioned on a hypothesis, and far cheaper than a Shopify build that has to be abandoned. Q: Is high order volume alone a reason to leave? A: Only when per-order fees exceed what running the alternative would cost, including the engineering to run it. Model it with real numbers. Q: Can apps solve any platform limit? A: No. Apps extend what the platform exposes. Where checkout does not expose a hook, no app creates one. Q: What if only one of my rules does not fit? A: Ask whether the rule is essential or habitual. Reshaping one rule is often cheaper than changing platform. ## Shopify against the alternatives, without the sales pitch https://shopifydevelopment.info/guides/shopify-vs-other-ecommerce-platforms Updated 2026-08-04 · Shopify basics - The comparison is really about how unusual your rules are. - Hosted platforms absorb undifferentiated work worth outsourcing. - Open source trades licence cost for maintenance you must staff. - Custom is justified when the commerce rules are the product. Platform comparisons are usually written by someone selling one of the options. The useful version starts from a different question: how strange are your requirements? Ordinary requirements are cheapest on a hosted platform. Unusual ones get expensive there very quickly, and that is the whole comparison. ### What each option is good at | Time to launch | Weeks | Weeks to months | Months | | Who runs the servers | Shopify | You or your host | You | | Checkout control | Limited by design | Yours | Yours | | Ongoing cost | Plan plus apps plus fees | Hosting plus plugins plus maintenance | Engineering team | | Unusual pricing rules | Hard or impossible | Possible | Whatever you write | | Best when | Standard retail, speed matters | You need control and have skills | Your rules are the product | ### The questions that actually decide it - Can your pricing and entitlement rules be expressed in the platform's checkout? - Does your catalogue fit a product-and-variant model, or is it configurable? - Do you have someone who will keep servers patched? If not, hosted wins by default. - At your order volume, do per-order fees become a material line? - Is the store a brand asset in its own right, or a way to take money? ### Where Shopify is clearly the right answer Standard retail, a catalogue that fits products and variants, a small team, and a need to be selling this quarter. The platform absorbs an enormous amount of undifferentiated work — PCI scope, uptime, checkout conversion, payment integrations — that you would otherwise buy. Undifferentiated work is the correct thing to outsource. Your competitors are not losing to you because of who patches their servers. ### Where it is clearly the wrong one Customer-specific pricing logic the checkout cannot express, a regulatory need to own the payment experience end to end, or a catalogue whose data model genuinely does not fit products and variants — configurable industrial goods being the classic case. Q: Is open source cheaper? A: The licence is. Hosting, security patching, plugin maintenance and the developer time to keep it running are not. Q: When is a custom build justified? A: When your commerce rules are the product, not the wrapper around it. That is rarer than it feels during planning. Q: Can I migrate later if I choose wrong? A: Yes, and it costs real money — mostly in data, redirects and rebuilt integrations. Choosing on evidence is cheaper. ## A realistic Shopify setup checklist https://shopifydevelopment.info/guides/shopify-store-setup-checklist Updated 2026-08-04 · Shopify basics - Do data first and the theme last, or you will redo both. - Write down what makes an order correct before configuring anything. - Launch with one market, one payment method, one shipping rule. - Place and refund one real order before you open. The order you do things in decides how much you repeat. Teams that start with the theme spend the last week fixing product data; teams that start with the data spend the last week on the theme, which is far more pleasant. This is the sequence we use, with the reason each step sits where it does. ### The sequence that avoids rework - Decide what an order must contain to be correct. One page, written down. - Get the product data right: options, variants, SKUs, images, stock. - Set up payments and confirm the provider onboarding timeline. - Configure tax and shipping for your first market only. - Pick and install a theme close to what you need. - Customise in sections and app blocks, not scattered edits. - Add apps you can name a reason for, one at a time. - Test one real order end to end, including a refund. - Set up analytics and the reports you will actually read. - Write down who owns the store after launch. ### Why product data comes before the theme Your variant structure decides what the product page can do. Choosing a theme first means picking a layout for a catalogue you have not defined, and the mismatch shows up as customisation you did not want to buy. Export your catalogue to a spreadsheet and look at it as a table before importing. The inconsistencies are visible there in minutes. ### Launch narrow | One market | Additional countries and currencies | | One payment method that works | Wallets and buy-now-pay-later | | A clean catalogue | Bundles, subscriptions, pre-orders | | Basic transactional emails | Full lifecycle marketing | | One shipping rule | Rate tables per region | ### The test that catches most launch problems Place a real order with a real card, then refund it. That single loop touches payment, order creation, stock, email, and your accounting export. If it works cleanly, most of the store works. Q: How long does a straightforward setup take? A: Two to four weeks for a small catalogue on a standard theme, and most of that is product data rather than configuration. Q: Should I import products before choosing a theme? A: Yes. The variant structure decides what the product page has to do. Q: What is most often forgotten? A: Testing a refund, and deciding who maintains the store after launch. ## Shopify plans and fees, added up honestly https://shopifydevelopment.info/guides/shopify-plans-and-fees Updated 2026-08-04 · Shopify basics - The plan is the smallest and most predictable part of the bill. - App subscriptions grow one reasonable decision at a time. - Not using Shopify Payments adds a fee on every order. - Model plan plus processing plus apps plus maintenance before committing. Every comparison of Shopify pricing starts with the plan tiers, which is the least interesting part of the bill. The plan is predictable. What surprises people is everything stacked on top of it. Here is the whole cost, in the order it tends to arrive. ### What you actually pay each month | Plan | Fixed, predictable | The number everyone compares | | Payment processing | Percentage of every order | Unavoidable on any platform | | Extra transaction fee | Applies if you do not use Shopify Payments | Often the reason to switch provider | | Apps | $20–$200 each, monthly | The line that grows quietly | | Theme | One-off, or free | Small next to the rest | | Maintenance | 15–25% of build cost per year | Almost never budgeted | ### The app bill is the one to watch A dozen apps at $20 to $200 each will exceed your plan several times over, and it happens one reasonable decision at a time. Each app was justified on the day it was installed; the aggregate never gets reviewed. Put a quarterly app review in the calendar before you install the third one. Uninstall anything nobody can name a use for. ### Where the plan tier genuinely matters - Lower card rates at higher volume — worth modelling against your actual order count. - Shipping and reporting features that replace an app you were about to buy. - Staff accounts, if several people need admin access with different permissions. - Checkout extensibility, which is gated by plan and can decide feasibility outright. ### How to model it before you commit Take your expected monthly order count and average order value, apply the processing rate, add the plan, add the apps you already know you need, and add 20% of your build cost divided by twelve. That number, not the plan price, is what running the store costs. Q: Which plan should a new store start on? A: The lowest one that supports the features you have already decided you need. Upgrading is easy; paying for headroom you do not use is not. Q: Are transaction fees avoidable? A: The extra Shopify fee is, by using Shopify Payments where it is available. Card processing itself is not avoidable anywhere. Q: How much should I budget for apps? A: Model your known list, then assume it grows. Teams that budget zero for apps end up surprised within a quarter. ## What Shopify development actually involves https://shopifydevelopment.info/guides/what-shopify-development-involves Updated 2026-08-04 · Shopify basics - Shopify development is building inside a boundary you do not control. - Theme, apps and integrations are three jobs with different risks. - Checkout, orders and customers belong to the platform, not to you. - Test your three hardest rules against the platform before you build. Ask five people what Shopify development means and you will get answers about themes. That is the part you can see, and it is rarely where a project succeeds or fails. Building on Shopify is building inside a system you do not control. The craft is knowing which of your requirements fit inside that boundary, which have to be reshaped, and which mean Shopify is the wrong platform entirely. ### The three layers of a Shopify build | Theme | Liquid templates, sections, settings | Nobody — this is what gets budgeted | | Apps | Admin and storefront extensions via public APIs | Most teams, on cost rather than effort | | Integrations | Data moving between Shopify and your other systems | Almost everyone | | The boundary | Checkout, orders, customers, payments | Everyone, every time | ### What the platform keeps for itself Checkout, the order model, the customer record and the payment flow belong to Shopify. You can extend parts of them on some plans, but you cannot replace them. That single fact removes whole categories of requirement — and it removes them before design, not after, if anyone asks early. Write your three hardest business rules on one page and try to express them in Shopify's product, variant and order model. Do it before you commission anything. ### Where projects actually go wrong - Product data that does not survive contact with a real variant structure. - A pricing rule that depends on who is logged in, discovered after the theme was signed off. - Apps chosen one at a time until the monthly bill exceeds the plan several times over. - A theme customised so heavily that the next platform update breaks the product page. - No decision about who maintains the store after launch. ### What good looks like at launch A well-maintained theme close to standard, a clean catalogue, one payment method that works, and three apps that each earn their subscription. Everything else belongs to month two, and most of it should. Q: Is Shopify development the same as web design? A: No. Design is one layer; the commerce rules, apps and integrations behind it carry most of the effort and nearly all of the risk. Q: Do I need a developer for a first store? A: Not always. A standard theme covers a simple catalogue. You need a developer when your rules do not fit the platform as it ships. Q: What causes most delays? A: Product data, followed by discovering a requirement the checkout cannot express.