A launch scope covers the catalogue model, the templates that carry the selling, the configuration the business runs on, and the handover afterwards.
Most of them are made once and then lived with for years.
A Shopify store is quick to open and slow to correct. The decisions that decide how well it trades are made in the first fortnight, before anything looks like a website.
The first is the catalogue model. Shopify keeps a deliberately narrow product structure, so a range described by size, colour, length and finish has to be resolved into options, separate products, or metafields before a single row is imported. That is not a styling question. It sets what can be filtered, what can be reported on, how stock is counted and how painful every future bulk edit will be.
The second is the template set. A store needs homepage, collection, product, cart and account templates that hold up against the catalogue you actually have, including the ranges with two photographs and the products with forty variants. Demo catalogues hide exactly the cases that cause trouble.
The third is operational. Payment providers, tax registration and rates, shipping zones and rates, notification wording, staff permissions, order tagging and the apps allowed to touch an order. None of it appears in a design review, and all of it appears in the first week of trading.
Each one has a written answer in the scope, not an assumption.
Swipe the decisions
One
How products, options, variants, collections and metafields represent the range, including the parts of it that do not fit a three-option product.
Two
Which templates exist, which are variations, and which parts of them the team can rearrange afterwards without a developer.
Three
The settings that decide whether an order can actually be taken, charged, picked and delivered without manual repair.
Four
Named owners for merchandising, content, stock and support, agreed while the build can still be shaped around them.
Named on both sides so the boundary is visible before anyone starts.
| Area | In a launch build | Quoted separately |
|---|---|---|
| Design | Theme implementation or restrained adaptation across the launch template set | Brand identity, logo design and photography direction |
| Catalogue | A defined product count imported and structured to the agreed model | Copywriting, retouching and specification data that does not yet exist |
| Configuration | Payments, tax, shipping, notifications, locations and staff access | Accounting, ERP and warehouse integrations |
| Search visibility | A technical baseline: titles, structured data, sitemap, robots and clean internal linking | Ongoing SEO work and content production |
| Analytics | Analytics and consent implementation with the standard commerce events | Paid media setup, feeds and channel management |
| After launch | Training, documentation and a short defect-fix period | Monthly support, and new features requested after sign-off |
A build that has to carry data out of an existing platform is a migration, priced and run as its own piece of work.
A checklist, run and recorded, rather than a launch-day opinion.
Sign-off is a list of things that have been observed working, not a general feeling that the site looks finished.
Where something on this list cannot be true at launch, it is written down as an accepted risk with an owner and a date, rather than discovered later.
A store the internal team cannot change is an expensive store.
The measure of a build is whether the business can run it a quarter later without ringing the person who made it.
That means the template settings are explained in the terms the team uses, the catalogue rules are written down, and the decisions that look arbitrary in six months have a recorded reason. It also means being honest about what needs development capacity: some things should not be editable, and pretending otherwise produces broken pages.
Monthly support exists for stores with a genuine backlog worth prioritising. It has never been a condition of a build here, and a build ends with a handover either way.
Published starting figures in GBP and USD, excluding VAT.
Fixed, from-price or scoped after discovery
Migration and build
From £5,000From $6,500
Moving to Shopify and building the store in one project, so the data and the storefront land together rather than in two disconnected pieces of work.
Starting price
Plus, B2B, multi-market
From £8,000From $10,500
Shopify Plus, B2B, multi-market, multi-language, custom integrations or headless work. These configurations are sized after discovery, not instant-priced.
Starting price · scoped after discovery
One bounded piece
£1,500$2,000
One bounded improvement: landing pages, a template rebuild, an analytics implementation, or a build-readiness review credited against a larger project.
Fixed price
Starting figures in GBP and USD, excluding VAT. Catalogue size, the number of distinct templates, integrations and market or B2B requirements are what move a launch build off its starting price.
The build is rarely the constraint. Catalogue data, photography, copy and the decisions only the business can make are what set the date, so the schedule is agreed against those inputs rather than against a standard number of weeks.
Usually not at launch. A restrained adaptation of a well-built theme gets a new store trading sooner and leaves budget for the catalogue and configuration work that actually decides whether it sells. Where the theme itself is the constraint, we say so and explain why.
Yes, once the catalogue model is agreed. The import itself is straightforward. Deciding what a product is, what a variant is and what belongs in a metafield is the part that takes the time and the part that is expensive to redo.
Then it is a migration, and it is scoped as one. Data mapping, redirects, integrations, validation and cutover change the shape and the price of the project, so they are handled on their own terms rather than folded into a launch build.
Catalogue shape, markets and the systems the orders have to reach are enough to size a launch build honestly.
