The complete guide to building a custom Shopify store
A custom Shopify build replaces theme configuration with templates written to your requirements. It runs in six stages across roughly eight weeks: discovery and platform fit, information architecture, design, build in Liquid, migration and testing, then launch and optimisation. The largest variable is how quickly product data and content arrive.
Most guides to building a Shopify store describe the admin interface. This one describes the project: what happens in which order, what decisions get made when, and where builds go wrong.
Should you build custom at all?
Start here, because the honest answer is often no.
A configured theme is the right choice when your catalogue is modest, your checkout is standard, and your requirements fit what the theme’s settings already expose. It launches in weeks rather than months and costs a fraction as much. If that describes you, buy a good theme and spend the difference on photography.
A custom build earns its cost when:
- You have many templates that need to behave differently from one another
- Your product data has structure a theme cannot represent
- You are integrating with systems the theme knows nothing about
- Your brand needs a storefront that does not look like a theme
- You have outgrown a theme and are fighting it on every change
Stage 1 — Discovery and platform fit (1 week)
We audit the catalogue, order volume, integrations and business rules to confirm Shopify is the right platform at all, and document every place it will need extending.
The output is a list of requirements Shopify handles natively, requirements needing an app, and requirements needing custom code. That third list is what drives the estimate, and producing it before quoting is what stops a project discovering its real scope in week six.
Stage 2 — Information architecture and UX (1–2 weeks)
We map collections, navigation, filtering and the checkout path, then wireframe the templates carrying the most revenue: home, collection, product and cart.
Note the ordering. The home page is usually the least commercially important template on a store and it consistently receives the most attention. Most sessions that convert arrive on a product page from search or an ad, and never see the home page at all.
Stage 3 — Design (2 weeks)
We design the full template set in Figma against a component library, so every page is assembled from the same reusable parts rather than designed in isolation.
Designing against a component library rather than page by page is what keeps the build predictable. When a designer invents a new card style on the fourth template, that is a new component, new code, new test surface, and new maintenance.
Stage 4 — Build (3–4 weeks)
The theme is developed in Liquid using Online Store 2.0 sections, apps and APIs are wired up, and markets, shipping and tax are configured for your selling regions.
Some specifics worth knowing:
Sections everywhere. Online Store 2.0 allows sections on every template, not only the home page. Building this way means your team can rearrange layouts afterwards without a developer. It costs slightly more upfront and saves continuously.
Metafields before apps. A great deal of what stores install apps for is structured product data — specifications, care instructions, sizing. Metafields and metaobjects handle this natively, with no monthly subscription and no injected script.
Shopify Functions for logic. Discount, shipping and payment customisation logic runs as Shopify Functions rather than as checkout scripts. This is the supported route and it survives platform updates.
Theme app extensions over script injection. When an app must add frontend behaviour, a theme app extension is scoped and removable. A script injected into the theme is neither, and it is how stores accumulate code nobody can identify two years later.
Stage 5 — Migration and QA (1–2 weeks)
Products, collections, customers and order history migrate through the Admin API. Then the testing, which matters more than the transfer.
Two things reliably break, and neither is the catalogue.
The first is URL structure. Shopify enforces /products/, /collections/ and /pages/ prefixes, so almost every legacy URL changes. Every one needs a redirect. Skipping this is the most common way a migration loses search traffic, and the loss appears three weeks later when it looks like an algorithm update rather than a self-inflicted wound.
The second is customer passwords. They cannot be migrated — the hashes are not portable. Every customer must reset. That means the reset email needs to be written, scheduled and tested before launch, not discovered afterwards when support tickets arrive from people who cannot log in.
Testing covers checkout across devices, payment methods, tax rules for each selling region, and every transactional email. Email templates are the most commonly forgotten item on a migration checklist.
Stage 6 — Launch and optimisation (1 week and ongoing)
We launch, then watch Core Web Vitals and checkout completion for the first weeks and prioritise fixes based on where real users actually drop out.
A launch is a starting point for measurement, not the end of the project. The store as launched is a hypothesis; the first month of real traffic is the test.
What it costs to run afterwards
Budget explicitly for these, because they recur:
- Shopify’s platform subscription — predictable
- Transaction fees — unless using Shopify Payments
- App subscriptions — the largest and least predictable line, and the one nobody audits
- Development — proportional to how often the store changes
App costs deserve particular attention. Each app looks inexpensive monthly. Twelve of them do not. We audit the app list at launch and again at six months, and removing unused apps is routinely the fastest performance win available.
What we need from you, and when
The most common cause of a build running late is not development. It is waiting for content.
Before stage 2 (information architecture):
- A complete product list with categories, even in spreadsheet form
- Any existing analytics access, so decisions are informed by real behaviour
- A list of every system the store must talk to
Before stage 3 (design):
- Brand assets — logo files, fonts, colour references
- Product photography, or a date when it will exist
- Any imagery you have rights to use
Before stage 4 (build):
- Access to the systems being integrated, with credentials that work
- Final decisions on shipping rates and tax configuration
- Legal pages — privacy, terms, returns
Before stage 5 (migration):
- The complete catalogue export from the current platform
- A decision on what happens to order history
- Sign-off on the redirect map
Photography is the single most common delay, and it delays stage 3 rather than stage 6, which means it stops everything behind it. Starting photography early is the cheapest schedule insurance available on any ecommerce project.
Common ways Shopify builds go wrong
Patterns we have seen repeatedly, all avoidable.
Designing the home page first, and at length. It is usually the least commercially important template. Product and collection pages carry the revenue, and they receive whatever attention is left.
Choosing apps during the build rather than before. Each app added mid-build changes the frontend, sometimes conflicting with what was designed. Decide the app stack in discovery.
Treating the redirect map as a launch-week task. It belongs in the migration stage, sized properly, with time to test.
No staging discipline. Shopify’s theme preview is not the same as a full staging environment with representative data. Test with realistic catalogue volume, not with three sample products.
Skipping the transactional emails. Order confirmations, shipping notices and password resets all need rebuilding and testing. They are invisible until launch day, when every one of them fires at once.
Nobody owning content. The build finishes and the store waits three weeks for product descriptions. Assign this at kickoff.
The pre-launch testing checklist
What we work through before a Shopify store goes live:
Checkout
- Complete a real purchase on desktop and on mobile
- Test every enabled payment method, including wallets
- Test with a discount code, and with an invalid one
- Test with a shipping address in every region you sell to
- Confirm tax calculates correctly per region
Catalogue
- Spot-check migrated products against the source data
- Confirm variant availability displays correctly, including sold-out combinations
- Check collections populate as expected
- Verify images transferred at full resolution
- Trigger and read every transactional email
- Confirm sender addresses and reply-to are correct
- Check they render on mobile mail clients
URLs and search
- Run the full redirect list and confirm each resolves in one hop
- Submit the new sitemap
- Confirm structured data validates
Performance and accessibility
- Core Web Vitals on product and collection templates
- Keyboard navigation through the full purchase path
- Contrast and focus states throughout
That list takes a day to work through properly and it is the difference between a quiet launch and a week of firefighting.
What happens in the first month after launch
Launch is where measurement starts. The first month typically produces:
Week one — small fixes surfacing from real traffic on real devices. Something always behaves differently in the wild than in testing. This is normal and worth reserving time for rather than treating as a defect.
Week two — the first meaningful Core Web Vitals field data begins accumulating. Lab scores from the build are indicative; field data is what counts.
Weeks three and four — enough checkout data to see where people actually drop out, which is nearly always somewhere the build did not anticipate.
Reserving a small amount of budget for this period is the difference between a store that improves after launch and one frozen at its launch assumptions.
Structuring content so it stays editable
A recurring frustration after launch is that changing anything requires a developer. Much of that is avoidable at build time.
Use sections and blocks generously. Anything the business might want to reorder, hide, or duplicate should be a section with settings rather than hardcoded markup. Hero content, feature rows, trust bars, promotional banners, FAQ blocks.
Expose the right settings, not every setting. A section with forty settings is as unusable as one with none. Expose what will genuinely change — text, images, links, ordering — and hardcode what should not, such as spacing and type scale. Letting a section’s padding be edited is how design systems degrade.
Use metaobjects for repeated content types. Store locations, team members, size guides, ingredient lists. Defined once as a structure, reused across templates, edited in one place.
Document it. A short page explaining which section does what, written at handover, saves an enormous amount of future support time. Most builds skip this and it is close to free to produce.
Where the estimate actually comes from
Useful to understand if you are comparing quotes, because two quotes for “a Shopify build” can differ by a factor of three legitimately.
The drivers, in rough order of impact:
- Template count. Not page count — template count. Fifty products using one product template is one template. Four product types needing genuinely different layouts is four.
- Integrations. Each system the store must talk to is scoping, building and testing. An ERP integration can exceed the cost of the storefront.
- Migration complexity. Catalogue size matters less than data quality. A clean export migrates quickly; inconsistent data needs cleaning first.
- Custom logic. Anything Shopify does not do natively.
- Content readiness. Not a development cost, but the largest schedule risk.
A quote that does not distinguish these is a guess. When comparing quotes, compare what each assumes about the five above rather than the headline number.
A note on theme updates
One consequence of a custom build worth understanding: you are no longer on an update path.
A purchased theme receives updates from its developer, which you can apply. A custom theme does not, because it is yours. That is not a drawback — it means nothing changes underneath you — but it does mean platform changes need watching. When Shopify deprecates something your theme uses, somebody has to act on it.
In practice this is a small, occasional maintenance item rather than an ongoing burden, and it is the same trade as any bespoke software.
