Shopify Development
Building well inside a platform whose rules you do not set
Shopify takes a great deal of work off your hands and takes some decisions away with it. URL patterns are fixed, checkout control depends on your plan, and every app you install has a performance cost somebody pays. Good Shopify work is knowing where the walls are.
The build decision
Three ways to build a Shopify storefront
This is the choice that actually shapes the project. It is not the same as choosing a platform, which has already happened by the time anyone reads this page.
| Dimension | Marketplace theme, customised | Custom theme | Headless storefront |
|---|---|---|---|
| Time to launch | Weeks | Two to four months for most catalogues | Longest, and the range is wide |
| Who can change things later | Merchandisers, through the theme editor | Merchandisers, if the sections were built for them | Developers, for anything structural |
| Theme updates from the author | Available, provided nobody edited the files directly | Not applicable — you maintain it | Not applicable — the storefront is your application |
| Performance ceiling | Set by the theme and by how many apps are installed | High, because you control what loads | Highest in principle, and easiest to squander in practice |
| Ongoing cost | Lowest | Moderate, and predictable | Highest — you own a front end forever |
| Where it goes wrong | Direct file edits that end update eligibility | Sections built so narrowly that every change needs a developer | Being chosen for a store that had no reason to need it |
Constraints
Where the platform actually bites
None of these are reasons to avoid Shopify. They are the things worth knowing before somebody promises you something the platform will not do.
- App sprawl, paid for twice.
- The subscription is the visible cost. The invisible one is third-party code loading on pages that never use the feature, extra requests on the product page, and an install history that has left dead fragments in the theme. Stores routinely find that removing four apps does more for page weight than any amount of image optimisation.
- Checkout is not yours to redesign.
- What you can change in checkout is set by your plan and by the extension points Shopify supports. That is a reasonable trade for not having to build and secure a payment flow, but it needs establishing before a designer produces a checkout concept nobody can implement.
- The same product lives at several addresses.
- A product reached through a collection has a different address than the product on its own, and variants appear as query parameters rather than separate pages. Shopify handles the canonical relationship, but merchandising, internal linking and analytics all need to agree on which address is the one you promote.
- Collections and tags were never given rules.
- Automated collections are easy to create, so stores end up with hundreds, many of them near-duplicates with almost identical contents. Deciding which collections deserve to exist, be linked and be indexed is a merchandising decision that nobody owns by default.
- Content is trapped inside an app.
- Product tabs, size guides, care instructions and landing sections often end up stored in a vendor app rather than in metafields. It works until you want to change vendor, at which point the content has to be rebuilt by hand.
The work
What a Shopify engagement covers
- A theme audit that lists every direct file edit and whether updates are still possible
- An app register recording what each app does, what it costs, and what it loads on which templates
- Section and block design so merchandisers can build pages without a developer
- Metafield and metaobject modelling for product content that belongs to you
- Collection and tag rules, including which collections should be linked and which should not
- Product template work for variants, bundles, stock states and pre-orders
- Checkout configuration and supported extensions within your plan
- Markets, currency and domain setup where more than one country is served
- Performance work on the templates that carry revenue, measured on real visits
- Analytics and consent configuration that survives a theme update
- Written handover covering every customisation, so the next person is not guessing
How we work
Our rules for working on someone else’s platform
We will
- Solve a problem in the theme before solving it with a new subscription
- Record the page-weight and monthly cost of every app before it is installed
- Keep customisations inside the supported extension points so updates stay possible
- Store product content in metafields rather than inside a vendor that owns it
- Tell you what your plan does not allow before design work begins
We will not
- Edit core theme files directly to save an afternoon and cost you every future update
- Install an app to add a badge, a countdown or a banner a section could render
- Design a checkout experience your plan cannot support and leave you to find out later
- Create automated collections in bulk without deciding which ones should be linked at all
- Leave an undocumented customisation behind for the next agency to reverse-engineer
Sequence
How a build or a rescue actually runs
Inventory the store as it stands
Theme lineage and direct edits, installed and abandoned apps, metafields in use, collection count, template weight measured on real visits, and which pages carry the revenue.
You get: A store audit with an app and customisation register
Decide the build route
Marketplace theme, custom theme or headless, argued from the audit rather than from preference. Most stores are better served by the least ambitious option that meets the requirement.
You get: A recommendation with the trade-offs written down
Model the content
Metafields, metaobjects, collection rules and template variants defined before anything is styled, so merchandisers get controls that match how they actually work.
You get: A content model and section specification
Build and reduce in parallel
New sections go in while redundant apps come out. Removing an app includes clearing what it left behind, which is the step most stores have never had done.
You get: A working theme with a shorter app list
Configure markets and checkout
Currency, pricing, domains or subfolders per market, language and country signals, and any checkout extensions supported by your plan.
You get: Configured markets and a checkout that matches the plan
Launch, measure and hand over
Staged release, field measurement on the revenue templates, and documentation covering every customisation so nobody has to guess later.
You get: Handover pack and post-launch performance report
Questions
What merchants ask before commissioning work
Do we need a custom theme, or can we customise a marketplace one?
A well-chosen marketplace theme, customised properly, is the right answer for a large share of stores. It is faster, cheaper, and it keeps you eligible for updates from the theme author.
Custom becomes worth it when the merchandising you need is genuinely unusual, when the brand cannot be expressed within the theme, or when the accumulated customisations have grown large enough that maintaining them costs more than a purpose-built theme would.
How much of checkout can we actually change?
It depends on your plan and on which extension points Shopify supports. Checkout is not an ordinary page you can edit freely, and the available customisation is provided through supported extensions and functions rather than by editing templates.
We will tell you before any design work starts what your plan allows, so nobody presents a checkout concept that cannot be built.
Why does app count matter so much?
Because most apps add third-party code to pages where their feature is not even used, and because uninstalling an app frequently leaves fragments behind in the theme. A store with a long app history is usually carrying code for features it removed years ago.
There is also a lock-in question. Once product data, reviews or page content live inside an app, leaving that app means rebuilding, so the decision to install is worth more thought than it usually gets.
Can we change our URL structure?
Only within limits. Shopify keeps products, collections, pages and blog posts under fixed prefixes, and those cannot be removed. You control the handles, not the shape.
What you can control is which pages exist, how they are linked, and whether a product is reached through a collection path or its own address. Those decisions matter more than the prefix ever will.
We want to sell in three countries. What is involved?
Shopify Markets handles pricing, currency and the domain or subfolder each market is served from. The setup itself is not the hard part.
The harder part is the content: whether each market gets genuinely localised copy, how the language and country signals are declared, and what happens to customers who arrive on the wrong market by accident.
Have someone look at the store before you rebuild it
Send us the store address. We will tell you whether the theme can still be updated, which apps are costing you the most on the pages that matter, and whether a rebuild is really the right spend.
If we don't deliver the work we agreed to deliver for reasons within our control, you don't pay for the undelivered work. Read our guarantee
Related
Where to go next
- choosing the platform in the first placeThe platform comparison lives there; this page assumes the decision is made.
- making a large catalogue findableCollection and variant structure is a search decision as much as a build one.
- measuring what the apps cost youApp weight shows up in field data before it shows up in revenue.
- growing an online store
- retail and ecommerce work
- improving what the store already gets
Last updated · Reviewed by Zubair Afzal