Checklist

The list every build is checked against.

48 core checks run on every build. Packs add more when a project needs them, and your scope names the ones that apply. You see the list before we start, and at launch you get it back with every check marked done, not needed, or left to you. The checks that run after launch are marked at day 30.

Nothing here promises a business result. Each check describes work we do and verify. It is not legal advice and not an accessibility certificate.

Last updated 23 October 2026.

On every build

The core list: 48 checks.

The basics of a safe launch: payments, order emails, search, your old addresses, launch day and the store being in your name. Each check is one sentence about the state your store must be in, with the reason it is on the list. We work on the platform your store needs. Stores and sites we have shipped run on Shopify, WooCommerce, Webflow and Framer.

Where a platform cannot do what a check says, the check is marked not needed, with the platform's limit as the reason.

Prices, discounts and payments

10 checks

1. Delivery cost, dispatch time and return window shown on product pages and in the cart match the shipping settings and policies.

Why: An old placeholder promises free shipping over 50 while the rate clears at 75, and the shopper finds out at checkout.
2. No sold-out product keeps taking orders, unless you can really backorder it and its page says when it ships.

Why: That setting arrives switched on through CSV imports and apps, so a sold-out product quietly keeps taking orders.
3. A test order is placed for each kind of discount in use, and the sale price shown matches the total charged.

Why: Sale badges come from tags or compare-at prices, so a page can advertise 30 percent off while the rule takes nothing off the total.
4. Payment is taken at purchase or held for approval, as agreed, and if held, the handover document names who approves.

Why: Manual capture with nobody assigned lets authorizations expire, so you ship orders that were never charged.
5. Tax settings (prices with or without tax, tax on shipping, tax per product type) follow written instruction from you or your accountant.

Why: A shopper in a tax inclusive market who watches the price jump at checkout abandons, and wrong tax is corrected order by order later.
6. Only the payment methods you agreed to are switched on, with test mode off and no test gateway left behind.

Why: Test mode left on accepts orders that never charge a card, and a leftover cash on delivery method lets buyers check out without paying.
7. A real card order is placed and refunded on the live store through each payment provider, and both appear in its report.

Why: Credentials that pass the admin connection check still fail on the first live charge when the merchant account is unverified.
8. A declined card and a card needing a bank check are tried: the cart survives and no order or double charge results, or the platform's own behaviour is written down.

Why: A declined payment leaves no paid order behind, so a checkout that drops the cart on a challenge passes every successful-order test. Where the checkout is the platform's, what it does is recorded, since it is not ours to change.
9. A real order is placed and refunded on a phone through each express button switched on, such as Apple Pay or PayPal.

Why: Express buttons skip the cart and use their own address and shipping steps, so a wallet that looks live but fails is found by the first real customer.
10. Every country you sell to is inside a shipping zone, and a test checkout in each zone shows a working rate.

Why: A weight bracket that stops short shows a no shipping methods available message and a checkout the shopper cannot finish.

Phones, browsers and speed

6 checks

11. Buttons on the product, category and cart pages are big enough for a thumb and far enough apart to hit the right one.

Why: Themes ship swatches and quantity buttons at 24 to 30px, so customers order the wrong size or delete a cart line by accident. The working minimum is 44 by 44 pixels with 8 pixels between neighbouring targets. The buttons inside the checkout are the platform's own.
12. The home, category, product and cart pages do not scroll sideways on a small phone.

Why: One oversized image or a fixed width size chart drags every page sideways and leaves add to cart half off screen. The pages are checked at 320 and 360 pixels wide.
13. The buy path, from home page to order confirmation, is run on a real iPhone and a real Android phone.

Why: Emulation does not reproduce Android font boosting, real touch scrolling or the Safari toolbar, so breakage first appears on customer hardware. The older Android and the iPad sit in the Speed and access pack.
14. The same buy path, with a filter used and an option changed, is run in current Safari, Chrome, Firefox and Edge.

Why: Safari handles sticky positioning, form controls and overflow scrolling differently, and desktop still carries a large share of higher value orders.
15. Speed is measured on the finished store, apps on and cookie banner showing; you get the results, slow spots fixed or explained.

Why: A store measured before its apps are on flatters itself: for example, an unpublished theme can score in the nineties and the same theme in the fifties the day after launch.
16. One purchase is completed using only the keyboard, and every blocker found is fixed or written down.

Why: Automated scans pass on pages where focus order is scrambled, so the failures that stop an order surface only when someone places one.

Search, the old addresses and the pages themselves

8 checks

17. Every product and category meant to be live is in the sitemap, and no sitemap address is broken, redirected or hidden from search.

Why: Products created by CSV import often arrive unpublished, so they look correct in admin while being invisible to shoppers and crawlers.
18. The old store's addresses that had visits or links in the last year are saved before the build, and after launch each one opens, or redirects in one step, to its matching page, not to the home page.

Why: Bulk redirect imports drop rows without warning and mistyped targets fail quietly, so breakage stays invisible until the traffic is gone. An old address sent to the home page tends to be treated by search engines as a missing page, so each one goes to the page that replaces it. Addresses nobody visited or linked to in a year are left out, which keeps the list one that can be checked line by line.
19. Every other form of the store's address (http, www, platform or staging) redirects to the main one or is switched off.

Why: When the same pages open at more than one address, Google picks one of them to show in its results, and it may not be the one you chose.
20. Nothing left over from development hides the live store from search engines: no password page and no leftover blocking setting.

Why: A global noindex left on in an SEO app makes Google drop each page from its results once it crawls it, and a leftover Disallow line stops Google reading the pages.
21. The live site is verified in Google Search Console under your own account, and its sitemap is submitted.

Why: A store nobody verified has no report of crawl errors, so an indexing problem after launch goes unseen.
22. No category page is empty, and every product on sale can be reached from the main menu.

Why: A product in no collection can only be found by search or a direct link, so it quietly stops selling.
23. The shipping, returns, privacy and terms pages carry your real details, with no placeholder text left and no wrong links.

Why: Generated policy templates ship with bracketed placeholders, and they go live that way unless someone reads them.
24. No demo, test or sample product is published, and no published product has a price of zero unless it is meant to be free.

Why: A published test product at zero price can be ordered by a real customer and indexed as an early search result.

Email and what happens after an order

6 checks

25. Order emails are signed as coming from your domain where the platform allows, test-sent to Gmail, Outlook and iCloud Mail, and where each landed is recorded.

Why: Unsigned confirmations are the ones that get filed as spam, which turns straight into did my order go through tickets and duplicate orders. The records that sign them (SPF, DKIM and DMARC) live in your domain's settings rather than in the email tool, and where a message lands is the mailbox provider's decision, so the check records it instead of promising it. Some platforms cannot send from your own domain; the check then records what the platform allows.
26. Every order, shipping and account email the store sends carries your logo, name and support address and no placeholder text, and replies reach a monitored inbox.

Why: Order confirmations are among the emails customers open most, and one naming the dev store produces support load from day one.
27. An awkward test order (two items, a discount, a second address line, non-Latin letters) arrives complete where orders are packed.

Why: Field mapping breaks on the second address line or accented characters, and engraving text missing from the packer's paperwork ships as wrong goods.
28. Every contact form on the live store is tested, and each message reaches a mailbox your team reads and can answer.

Why: A form pointing at a mailbox nobody opens swallows pre-purchase questions and return requests for months.
29. A test order is followed as a customer would, from confirmation email to tracking to the returns route, and each step works.

Why: Where is my order and how do I return this are among the most common support messages a store gets.
30. Where customer accounts are switched on, a new customer can sign up, sign in and reset a password on the live store.

Why: A sign-up or reset email that never arrives locks a customer out of their orders, and you hear about it as a support message or a lost order. Where the platform signs customers in with an emailed code and no password, the reset step is marked not needed.

Launch day

7 checks

31. One real order on the live store is recorded exactly once in analytics, with the right order number, currency and value.

Why: Broken value mapping sends 0.00 or one line item price, and a leftover pixel quietly doubles the same order.
32. We give your team a written script for the buy path; named people on your team run it before launch, and each problem is fixed or accepted in writing.

Why: Every other test is us checking our own work, so without this there is no moment where you accept the build.
33. The launch runs from a written plan with a named owner for each step and a way back, outside your busiest hours and campaigns.

Why: Improvised cutovers skip steps under pressure, and launching during a promotion puts the busiest hours inside the riskiest window. The way back is the saved copy from the version check and the written steps in the handover document.
34. If launch changes where your domain points (its DNS records), the old ones are saved first, then checked after, and a test email is sent and received.

Why: A switch that drops the mail record stops your company email, including the inbox your customers reply to.
35. The live store opens securely (HTTPS) on the main address, the www address and a product page, with no browser warning.

Why: The certificate is issued once your domain's records point to the platform, and on Shopify that can take up to 48 hours, so a store that looks live can show a security warning until then.
36. Straight after launch, a real paid order is placed on the live domain from a phone, checked end to end, and refunded.

Why: Checkout behaves differently on the live domain than in preview, and a gateway left in test mode loses every real order.
37. Within an hour of launch, page views, add to cart and purchase are recorded in your live analytics, not a development copy.

Why: Development IDs survive the move more often than anyone expects, so launch week lands in a test property or nowhere.

Ownership, handover and the first 30 days

11 checks

38. No password or secret key is left in the store's code or in the page source.

Why: Keys pasted into a theme file during build stay in the published theme and are readable by anyone who views source.
39. The store's owner account, domain, subscriptions and billing card are in your name, and we hold only a login you can remove.

Why: A store or a domain registered to an agency's account is hard for you to get back if the relationship ends.
40. A copy of the launched code is kept in your own repository (for example GitHub), or in a named backup where the platform keeps no code.

Why: When the code exists only in the platform's admin, one overwritten section is gone for good. The launch is tagged in the repository so it can be found again.
41. Before the new version goes live, the one live now is saved as a dated copy that can be put back.

Why: Without a saved copy a broken launch has nothing to put back within minutes. On Shopify, for one, a theme you replace is kept as a draft, but edits to the live theme itself can be undone only one file at a time.
42. Products, categories, customers, discount codes and redirects are exported to files kept where you can reach them without asking us.

Why: A bad bulk edit can overwrite thousands of records, and most platforms offer no undo for catalogue data.
43. Logins with access to orders or the store are reviewed against who still needs them, two-step sign-in is on, and access keys are listed.

Why: Build projects leave standing keys and freelancer logins with access to orders and customer data for years.
44. For seven days after launch, orders, failed payments and broken pages are checked daily, and each issue is fixed or reported to you by day 30.

Why: The first week surfaces what no test catches, and an issue nobody wrote down falls between you and us. The day 1, 7 and 30 recrawls belong to the 30 days after pack, and the abandoned checkout emails are tested in the Connected systems pack.
45. You get a recorded walkthrough, as a file and a link, of editing each custom section, adding a product, publishing and going back.

Why: What is obvious to whoever built the store is not obvious to your team, so the store stops being updated.
46. A written handover document lists every app and its monthly cost, every outside account and owner, where the code lives and how to roll back.

Why: Undocumented apps keep charging for tools nobody remembers, and the next developer rebuilds code they cannot find.
47. Every account opened during the build, such as analytics, the email platform and review tools, has your email as owner by day 30.

Why: An account under an agency's email becomes unreachable to you when the work ends, and its history goes with it.
48. A support note you confirm by reply sets the 30 days of fixes, one reporting channel, a one-business-day first reply and what counts as a defect.

Why: Without a written window and a business day clock, every request after launch is negotiated one by one.

Added by scope

The packs, added when a project needs them.

A pack is a fixed set of checks. Which packs apply is written into your scope and priced with it. Every check in a named pack ends up marked like the core ones: done, not needed, or left to you.

Moving platforms

16 checks

Adds: Customers, balances, reviews and every old address brought across, the old store switched off cleanly, and a way back if the switch goes wrong.
Applies when: The store moves from one platform to another, or replaces an older site.

For example

Every old address with visits or links is mapped to one new page before the move.
Every unspent gift card and store credit balance is recreated and reconciled to the old total.
The old store is stopped from taking orders, proved by trying to check out on it.

In the full list: Scope and decisions before build starts (2), Search visibility and safe migration (4), Catalogue and content quality (1), Bringing existing customers and their balances across (4), Launch day (5).

Connected systems

20 checks

Adds: Orders, stock and customer data tested end to end with everything the store talks to, including what happens when a message arrives twice or not at all.
Applies when: A warehouse, an ERP, an email platform, a subscription or returns app, or a custom automation exchanges data with the store.

For example

The same order sent twice creates exactly one record in each connected system.
A checkout with the marketing box ticked and one with it unticked reach the email platform correctly.
Cancelling a test order reaches the warehouse and stops the shipment there.

In the full list: Scope and decisions before build starts (2), Payments, shipping, tax and discounts (3), Catalogue and content quality (1), Order emails from your own domain (1), Orders, stock and connected systems (12), What happens after someone orders (1).

Tracking and ads

17 checks

Adds: A written measurement plan, every step of the funnel tested, consent handled in both states, and the numbers reconciled against real orders.
Applies when: You spend on ads, or you steer spending from the analytics.

For example

A written measurement plan lists every event, what it carries and who owns each account.
Google Ads conversions come from one source only, never two.
The first seven days of sales in analytics are reconciled against the store's own order reports.

In the full list: Measurement and ad platforms (17).

Speed and access

25 checks

Adds: A speed budget agreed up front and measured per template, a wider set of devices, and the accessibility checks beyond the basics. It is not a WCAG audit.
Applies when: Speed or accessibility is a goal of the project in its own right.

For example

A speed budget is agreed before the build and each template is measured against it.
Every text and button colour is checked against the background it sits on.
Key pages are tested at 200 percent zoom with nothing cut off.

In the full list: Scope and decisions before build starts (1), Phones, tablets and desktop browsers (1), Speed and visual stability (12), Access for everyone (11).

Design and message

39 checks

Adds: The documents behind a new design (wireframes with the real copy, a design system, every state drawn, a message map) and the checks on templates built from scratch.
Applies when: A full redesign or a new store, where the page types are designed and built new.

For example

Five people who have not seen the project take a recorded task test on a phone.
Greyscale wireframes with the real copy are approved before any visual design starts.
Your own editor completes five edits in the store's editor while we watch.

In the full list: Scope and decisions before build starts (1), What the store says, and to whom (10), How the store looks, and whether it stays that way (11), The product page and the road to the cart (7), Phones, tablets and desktop browsers (6), Machine-readable content and AI assistants (1), Payments, shipping, tax and discounts (1), Catalogue and content quality (1), Ownership, handover and life after launch (1).

Catalogue and search

27 checks

Adds: Product data, images, filters, on-site search and how discounts stack, checked across the catalogue, plus the markup that search engines and AI assistants read.
Applies when: A large or complex catalogue: many products or variants, several markets or currencies, gift cards, or a store that lives on search.

For example

Twenty real search terms, including misspellings, each bring up the expected product.
Every colour or finish option has its own image, and the gallery jumps to it.
Tags, option names and values are tidied to one spelling so filters stay clean.

In the full list: How the store looks, and whether it stays that way (1), The product page and the road to the cart (3), Search visibility and safe migration (4), Machine-readable content and AI assistants (8), Access for everyone (1), Payments, shipping, tax and discounts (3), Catalogue and content quality (7).

30 days after

7 checks

Adds: The longer watch after launch: recrawls on day 1, day 7 and day 30, an uptime monitor, speed data from real visitors, and recorded sessions turned into a ranked list of changes.
Applies when: A quiet failure after launch would be expensive: a move, a busy store, or a launch just before a sales peak.

For example

Session recordings of shoppers who stalled are turned into a ranked list of changes.
The store is recrawled on day 1, day 7 and day 30 and compared with the baseline.
A hosted uptime monitor alerts a named person on our side and one on yours.

In the full list: What the store says, and to whom (2), Speed and visual stability (1), Search visibility and safe migration (1), Machine-readable content and AI assistants (1), Measurement and ad platforms (1), Ownership, handover and life after launch (1).

Large builds run the whole list: the core list and every pack, 199 checks.

At launch

You get the list back, marked.

You see the list for your project before we start: the core list and the packs your scope names. At launch it comes back as your own copy, with every check on it in one of three states. The checks that run after launch are marked at day 30.

Done: We did what the check says and verified it.
Not needed: The check does not apply to your store or to this launch. The copy says why.
Left to you: The check depends on your decision, your content or your access, and it was still open at launch. The copy says what it is waiting for.

The marked copy is yours to keep, with the code, the documentation and the recorded walkthrough.

Launch checklist yourstore.com Example: your copy at launch

Done: A real card order is placed and refunded on the live store through each payment provider, and both appear in its report.
Done: The buy path, from home page to order confirmation, is run on a real iPhone and a real Android phone.
The shipping, returns, privacy and terms pages carry your real details, with no placeholder text left and no wrong links. Left to you. The returns page still needs your returns address.
If launch changes where your domain points (its DNS records), the old ones are saved first, then checked after, and a test email is sent and received. Not needed. This launch did not change your DNS records.
Done: The store's owner account, domain, subscriptions and billing card are in your name, and we hold only a login you can remove.

Done
Not needed
Left to you

The checks on this example are from the core list.

The whole document

The full list: 199 checks.

The core list and every pack, in the groups we work through. Each check says which tier it belongs to. Checks in a pack are written as working instructions and keep their detail.

A check tagged Shopify names a Shopify feature. On another platform it is marked not needed, unless your scope names an equivalent. A check with a condition runs only when the condition holds.

The free store checkup reads one page of your store and links each of its findings to the group below that covers it.

Scope and decisions before build starts 6 checks

List every app and custom integration on the current store with its monthly cost, mark each keep, replace or drop, name the specific Shopify replacement for anything with no direct equivalent, and get written client approval before design starts. Why: Subscriptions, bundles, loyalty and ERP tools rarely move one to one, and finding that out in week six is what breaks scope. Only when: migrating from an existing store. Moving platforms Shopify
Write down which historical records move and which do not, covering customer accounts, past orders, subscribers with their consent state, gift card and store credit balances and loyalty points, naming the tool, the cut-off date and the person who runs each import. Why: Passwords never transfer and stored value is money already owed, so day one for returning customers is decided here. Only when: migrating from an existing store. Moving platforms
Write a one-page integration map listing every system that exchanges data with the store, the direction of each flow, and the single system that owns each shared field including price, inventory, customer record and marketing consent, approved by the client in writing. Why: With no named owner per field, the ERP and Shopify overwrite each other and nobody can say which stock number is real. Connected systems
Take the browser, operating system and screen size mix from the client's existing analytics for the last 12 months, write down the versions covering 95 percent of sessions and 95 percent of revenue as the test matrix for the build, and before launch run the purchase path on every device and browser in that matrix, including an older Android at 360px wide and Safari on an iPad, each on real hardware or a real device session in a device cloud, recording the model and version of each. Why: Revenue share and session share differ, and the devices worth testing are the ones this store's customers actually buy on. Speed and access
Agree a written content plan listing every item the client must supply (product copy, photography, size charts, policy text, reviews export) with an owner, a due date and the named fallback that ships if the item is late. Why: Photography nobody was assigned to shoot is the usual reason a finished build sits unlaunched for three weeks. Design and message
Record in writing which email platform the client has chosen, whether Craftive recommended it for their needs or the client brought it, and whether setting it up is inside the build scope or quoted separately. Why: With nothing written down the setup lands on whoever assumed it was included, and that is discovered in the week the store is meant to launch. Connected systems

What the store says, and to whom 12 checks

Write one page before design starts that names, for each template in scope, how much the visitor landing there already knows (does not know they have the problem, knows the problem, comparing approaches, comparing brands, ready to buy), the traffic that brings them, and the one question the first screen has to answer, with each question quoted word for word from a customer review, a support ticket or a return reason. The client approves this page in writing before any visual design file is opened. Why: Without it every template gets written for someone who already knows the brand, so a cold visitor from an ad lands on a page that answers none of the questions they arrived with. Design and message
Collect the exact wording of every offer and ad headline the client runs or plans to run, or a written note that they run no paid traffic, and record in one table the campaign, the page it lands on and the headline on that page, confirming the first screen repeats the same offer and names the same product or category. Why: A click bought on a promise of 20 percent off lands on a generic homepage, so the visitor has to hunt for what was advertised and the click is paid for either way. Design and message
Agree in writing, before the first conversion change is proposed, how changes will be judged: the weekly order count the store needs before a split test is worth running, and the named evidence used below that count, such as before and after periods of equal length with seasonality noted, session recordings, or a task test with five people. Why: At this order volume most split tests never reach a clear result, so with no agreed rule every change is either argued over for weeks or called a win off one good week. Design and message
Write the homepage claim stack as a numbered list holding one main claim and no more than three supporting claims, with the proof named beside each one (review count and its source, a named customer quote, a certificate, the returns or warranty text), then check on the built page that every hero line, heading, announcement bar line and badge maps to one entry on that list and that each claim's proof renders in the same section. Why: Six claims set at the same size across the announcement bar, hero and badge row leave the visitor carrying none of them to the collection page, and a claim whose proof sits two pages away reads as marketing. Design and message
Record in the design file which product page blocks are decision copy (what it is, what it is made of, how it fits, when it ships, what happens if it is wrong) and which are brand copy (story, origin, values), then check on three real products that the first 50 words under the title are decision copy and that brand copy sits below the buy block. Why: Brand story placed between the title and the price pushes the facts people buy on off the first screen, so the shopper opens a competitor tab to find them. Design and message
Where the scope includes it, publish one block or page that answers why this brand rather than the other tab the shopper has open, holding at least three factual points of difference (materials, where it is made, warranty length, delivery time, return cost, size range), each supplied by the client in writing, and link it from the main navigation and from the product page. Why: A shopper comparing two stores with nothing stated between them decides on price alone, which is the one comparison a small brand loses. Design and message
Where collection copy is in scope, give every collection linked from the main navigation, and every collection used as a paid traffic destination, its own intro text saying who the category is for and how to choose between the products in it, then export all collection descriptions and confirm none of those is empty and no two hold the same text. Why: A grid that opens straight into 40 similar products leaves a first time visitor no way to narrow them down, and one description pasted across five collections tells them nothing about any of them. Design and message Shopify
Name one primary action per template in the design file, then check on the built page at 375 pixels and at desktop width that within the first screen only that action uses the primary button style, with newsletter, chat, wishlist and promo calls to action in the secondary or text style defined in the design system. Why: When signup, chat and add to cart all look equally important on the first screen, the visitor takes the easiest one and the store collects an email address instead of an order. Design and message
Build one register of every superlative, number, guarantee and certification in the site copy (for example best, hand made, ships in 24 hours, 100 percent organic, trusted by 10,000 customers) and of every urgency, scarcity and social proof element in the theme, recording the source behind each line: stock counters read the variant's real stock, countdowns end at a real date, review and order counts come from the store's own records. Delete or rewrite every line that has no source before launch. Why: Invented low stock counters and numbers carried over from the old site are what draw a consumer protection complaint or a competitor challenge, and by then nobody can say where the figure came from. Design and message
Run a recorded task test with five people who have not worked on the project, at least three of whom buy online in this category, each asked on a phone to find a named product, pick the right variant and reach the payment step, and log every point where someone stopped, asked a question or chose the wrong option, with either the fix applied or a written decision not to fix it. Why: The people who built the store know where everything is, so the steps that stop real shoppers stay invisible until the orders do not arrive. Design and message
Install a session recording tool set to follow the store's consent banner and mask form fields, then in the first month after launch watch at least 20 recorded sessions that added to cart without ordering, log each point where the visitor stalled, repeated an action or left, and turn the log into a ranked change list naming the step each change targets. Why: Analytics shows the drop between two steps but never the reason, so the fix list gets built from guesses and the same step keeps losing orders. 30 days after
For every conversion change shipped inside the 30 day included post-launch window, record the date it went live and the figures for the step it targets over equal length periods before and after, judged by the rule agreed at plan stage, and write down plainly where the difference is too small to call at this store's order volume. Why: Changes get called winners off one good week, and the client keeps paying to maintain work that never moved anything. 30 days after

How the store looks, and whether it stays that way 12 checks

Produce a greyscale wireframe of the homepage, one collection template, the product template and the cart, showing every block in its final order with the real headline, body copy and button label in place, and get written client approval on block order and wording before the first visual design file is opened. Why: Block order and wording get argued about after the visuals exist, when changing them means redrawing pages in build week instead of editing a line of text. Design and message
Record one line in the design file for every block on the homepage, the collection template and the product template, naming the buyer question or objection that block answers and the evidence behind it, such as a support ticket, a product review, a return reason or a quote from the client interview, and remove any block where that line cannot be written. Why: Blocks copied from a reference store push the products and the add to cart button down the page and add nothing that answers why to buy here instead of from the marketplace listing of the same item. Design and message
Produce one design system file naming every colour, type size with its line height and weight, spacing step, corner radius and border the build may use, with each value labelled by the shop role it plays: body copy, product title, price, sale price, compare at price, stock badge, button label and form label. The client approves this file in writing before any template is designed. Why: Without named roles the sale price is one red on the collection card and a different red on the product page, and by the time the catalogue is loaded nobody can say which one is the mistake. Design and message
Draw every state of the controls on the buy path before build starts: add to cart in default, hover, keyboard focus, loading, disabled and sold out, variant options in selected and unavailable, the quantity control, and the message shown when a cart action fails, so each state exists as a drawing a developer can build from. Why: States nobody drew get invented in code on the last build day, so the shopper taps add to cart, sees nothing change and taps again. Design and message
Write a photography specification before any product image is shot or supplied, naming for each product type the shot order (front, back, detail, scale or in use), the background, the crop margin, the aspect ratio, the minimum long edge in pixels, the file format and sRGB as the colour profile, confirmed in writing by whoever supplies the images. Why: Images otherwise arrive on three backgrounds with the product at three sizes in frame, and the only fix left in launch week is a reshoot nobody budgeted. Design and message
Send no template for client approval with placeholder content: every headline, body line, button label, badge and price comes from the approved copy document, and every product shown is a real product from the client's catalogue with its own title, price, variant names and photography. Why: Approval given on invented copy and square stock photos falls apart once a 70 character product title and a portrait photo land in the same grid, and the page gets redesigned after it was signed off. Design and message
Declare the design system colours and type sizes once in the theme as settings or variables, including the colours used for price, sale price, stock badge, swatch border and the add to cart button, then search the stylesheets and template files and confirm no colour value or font size is written directly outside that set, listing every exception in writing with the reason it stays. Why: With values pasted in by hand, a sale campaign that changes the badge colour updates the product page and leaves the collection grid and the cart drawer on the old one. Design and message Shopify
Fix one image aspect ratio and one card height for collection cards in the design system, then load a collection holding the tallest and the widest images in the catalogue and confirm the title, price and badge sit on the same line across every row at 375, 768 and 1440 pixels wide. Why: Mixed portrait and square photos push the price down by a different amount on each card, so a shopper scanning the grid hunts for the price on every product instead of reading down one line. Design and message
Open the three longest imported product descriptions and one spec table, list every inline font size, font family, colour and fixed width the supplier content carried in, then either strip it at import or override it so those pages render with the design system values, rechecked at 375 pixels wide. Why: Supplier HTML brings its own small grey text and fixed width tables, so the pages where shoppers check sizing and materials stop matching the store and overflow the screen on a phone. Catalogue and search
Run a design QA pass comparing the built store against the approved templates at the agreed screen widths across the homepage, collection, product, cart and customer account pages, log every difference in one list with a written decision to fix or accept, and close every line before launch day. Why: Type size, spacing and button weight drift during build, and with no logged comparison the store goes live looking different from the design the client approved and paid for. Design and message
Apply the design system logo, colours, type and corner radius to the surfaces the theme does not control: checkout branding, customer accounts, the order status page, every notification email the store sends, the 404 page and the password page, then open each one and compare it against the design system file before launch. Why: Checkout and the order confirmation email are where the money moves, and default styling there reads as if the shopper has been handed to a different company. Design and message Shopify
Replace free colour pickers and font size fields in the theme editor with named presets taken from the design system, and hand over a one page sheet saying which preset to use for each kind of content and section. Why: A month after launch the client builds a sale section, picks a new red and a bigger heading, and the store stops matching itself with no developer involved. Design and message

The product page and the road to the cart 13 checks, 3 in the core list

Phones, tablets and desktop browsers 11 checks, 4 in the core list

Deliver a mobile frame at 375 pixels wide for every template in scope, including the collection page with the filter drawer open, the product page with the variant picker and sticky buy bar, the cart and the account pages, signed off by the client before desktop build starts. Why: Where the sticky bar sits and how filters open are layout decisions, and making them in code means reworking them after review. Design and message
Buttons on the product, category and cart pages are big enough for a thumb and far enough apart to hit the right one. Why: Themes ship swatches and quantity buttons at 24 to 30px, so customers order the wrong size or delete a cart line by accident. The working minimum is 44 by 44 pixels with 8 pixels between neighbouring targets. The buttons inside the checkout are the platform's own. Core list
Where the design includes a sticky mobile add to cart bar, confirm it shows the selected variant, price and stock state, updates on variant change, appears only after the main button scrolls out of view, clears the iOS home indicator with env(safe-area-inset-bottom), and is never covered by the chat launcher or cookie banner. Why: A bar wired to the default variant adds the wrong size, and one under the home indicator makes the buy action impossible to tap. Design and message Shopify
Confirm every field in the cart, account, address and newsletter forms sets the matching type, inputmode and autocomplete attributes and renders at 16px or larger, verified by opening each field on a real iPhone and a real Android, either hardware the team owns or a real device session through a device cloud service, and seeing the correct keyboard with no page zoom. Why: A phone field that opens the letter keyboard and iOS zooming into a 14px input turn a two minute cart into a typing exercise. Speed and access
Confirm the mobile menu opens on one tap, reaches every top level collection without a hover step, locks background scrolling while open, and closes on the Android back button and the iOS back swipe. Why: Desktop hover states leave whole collections unreachable on touch, and a menu that ignores the back gesture forces people to leave the site. Design and message
Confirm collection filters and sort open within one tap from the top of the results, apply without a full page reload, keep the active filters and result count visible while scrolling, and update the URL so a filtered view can be shared and reloaded. Why: Filters parked below 40 products go unused on a phone, and in-memory filter state breaks every shared or advertised filtered link. Design and message Shopify
Confirm the mobile product gallery moves on horizontal swipe, shows the current position in the set, does not block vertical page scrolling during a swipe, and opens a full resolution zoom view on tap or pinch. Why: A gallery bound to touchmove without direction detection freezes vertical scrolling, and shoppers who cannot zoom do not buy considered items. Design and message
The home, category, product and cart pages do not scroll sideways on a small phone. Why: One oversized image or a fixed width size chart drags every page sideways and leaves add to cart half off screen. The pages are checked at 320 and 360 pixels wide. Core list
Confirm that with the on-screen keyboard open on iOS and Android, the focused field and its submit button stay visible without manual scrolling in the cart drawer discount field, the login form, and any address or popup form. Why: A fixed height cart drawer hides the apply button behind the keyboard, so the discount code can be typed but never applied. Design and message
The buy path, from home page to order confirmation, is run on a real iPhone and a real Android phone. Why: Emulation does not reproduce Android font boosting, real touch scrolling or the Safari toolbar, so breakage first appears on customer hardware. The older Android and the iPad sit in the Speed and access pack. Core list
The same buy path, with a filter used and an option changed, is run in current Safari, Chrome, Firefox and Edge. Why: Safari handles sticky positioning, form controls and overflow scrolling differently, and desktop still carries a large share of higher value orders. Core list

Speed and visual stability 14 checks, 1 in the core list

Agree a written performance budget before build starts naming the measured templates (home, top collection, three top products, cart, search), the LCP, CLS and INP thresholds, the maximum compressed JavaScript and image weight per template, and the exact tool and network profile used to check them, with the final measurement reported as the median of five mobile runs per template and anything over budget either fixed or written down and accepted before launch. Why: Without an agreed number, fast enough becomes an argument at launch when the only fix left is removing an app the client paid for. Speed and access
Name the LCP element for each measured template in the design handoff and confirm it is a static image or a text block, not a hero slideshow, an autoplaying video, or the first frame of a JavaScript gallery. Why: A carousel hero makes the largest paint wait for the library to boot, so LCP lands seconds late however well the image is compressed. Speed and access
Limit fonts to the weights and styles the design actually uses, served from the store's own domain or the Shopify CDN rather than a third party font host, with font-display: swap, a preload for the single face used above the fold, and a size-adjusted fallback family. Why: A third party font host costs an extra connection before text can paint, and mismatched fallback metrics reflow the hero. Speed and access Shopify
On every measured template the LCP image renders with loading="eager", fetchpriority="high" and explicit width and height, and no image inside the first mobile viewport carries loading="lazy". Why: Shopify section images default to lazy loading, and a lazy hero alone pushes LCP past four seconds on a throttled 4G phone. Speed and access Shopify
Generate every theme image through image_url with widths and a sizes attribute matching how it actually renders, checked on a 390px viewport so no image arrives at more than twice the CSS width it is displayed at. Why: Without width parameters the CDN hands a 3000px product photo to a phone, so one page pulls megabytes the screen cannot show. Speed and access Shopify
Measure CLS on each measured template in a fresh session where the consent banner has not been dismissed, with layout space reserved for the announcement bar, sticky header, app badges, product images and any embedded video, and confirm it stays under 0.1, with anything above that either fixed or written down and accepted before launch. Why: Teams test in a browser that dismissed the banner weeks ago, so the jump every first time visitor sees never appears in their numbers. Speed and access
Search theme.liquid, the layout files and all snippets for script tags and pixels left behind by uninstalled apps, and confirm the network log on each measured template makes no request to a removed app's domain. Why: Some apps leave code in the theme that uninstalling them does not remove, so inherited stores often still load scripts from apps that are gone. Speed and access Shopify
List every enabled app embed and theme app extension, record the templates each one is genuinely needed on, and disable or template gate the rest. Why: A reviews or upsell app loads its full bundle on the home page and cart where it renders nothing. Speed and access Shopify
Confirm every script the theme adds carries defer or async, and that heavy third party embeds such as video, live chat, Instagram feeds and store locator maps stay out of the network log until the visitor clicks a placeholder. Why: A chat widget and one video embed pull close to a megabyte during load and compete with the LCP image for bandwidth. Speed and access
Profile the home, collection and product templates with the Shopify Theme Inspector against the client's real catalogue size, record the total render time and the three slowest nodes for each template in the project doc, rework every node above 100ms that can be reworked inside the agreed scope, and write down any template still above the 300ms target with the reason and what was tried. Why: Nested loops and metafield lookups cost nothing on a ten product dev store and add a second of server time on the real catalogue, and on a very large catalogue the honest answer is a recorded number the client can see rather than a gate that quietly fails. Speed and access Shopify
Render at most 48 products per page on collection and search templates, and replace only the product grid through the Section Rendering API on filter or sort instead of reloading the page. Why: Grids of a hundred products stutter on mid range phones, and a full reload per filter click makes browsing feel broken. Speed and access Shopify
Measure INP for the interactions that carry the sale (variant switch, add to cart, cart drawer open, quantity change, filter apply, predictive search typing) on a 4x CPU throttled mobile profile and confirm each stays under 200ms, with anything slower either fixed or written down and accepted before launch. Why: A variant switch that re-renders the whole section feels like a dead site while Lighthouse still reports a green score. Speed and access
Speed is measured on the finished store, apps on and cookie banner showing; you get the results, slow spots fixed or explained. Why: A store measured before its apps are on flatters itself: for example, an unpublished theme can score in the nineties and the same theme in the fifties the day after launch. Core list
Twenty eight days after launch, inside the 30 day included post-launch window, pull field Core Web Vitals per template from the Shopify admin web performance report or CrUX, compare them with the agreed budget, and send the client the list of templates that fall outside it. Why: Lab runs on office wifi hide what real devices do, and field data is where an app installed in week three becomes visible. 30 days after

Search visibility and safe migration 14 checks, 5 in the core list

Before design starts, build a URL mapping sheet from a full crawl of the old site plus Search Console, analytics and a backlink tool, and give every URL with organic entrances or external links in the last 12 months exactly one destination URL on the new store, sending discontinued products to the closest replacement or their parent collection. Why: Any URL missing from the sheet becomes a 404 on launch day and loses the links holding its rankings. Moving platforms
Verify that a product opened through a collection path (/collections/x/products/y) carries a canonical tag pointing at /products/y, and that internal links, sitemap entries and hardcoded links all use the /products/ form. Why: Shopify serves the same product under every collection path, so a wrong canonical splits signals across duplicates. Catalogue and search Shopify
Confirm that filtered, tag and sorted collection URLs (?filter.v..., /collections/x/tag, ?sort_by=) carry a canonical tag pointing at the plain collection URL and appear neither in the sitemap nor as crawlable internal links. Why: Filter combinations generate thousands of thin near-identical pages that soak up crawling and push real collections down the queue. Catalogue and search Shopify
On collection templates, confirm paginated pages are reachable through real anchor links to ?page=2 and beyond in the server-rendered HTML, that each paginated URL is self-canonical, and that products past page one appear in a test crawl. Why: Load-more buttons and infinite scroll leave everything after page one uncrawlable, so a large catalogue loses most of its product pages. Catalogue and search Shopify
Carry the title tag and meta description of the top 50 organic landing pages across from the old site instead of leaving theme defaults, and confirm each product, collection and content page renders exactly one H1 holding the product or collection name rather than the store logo. Why: Themes wrap the logo in an H1 and apply one boilerplate title to every page, so ranking pages lose the wording they ranked for. Moving platforms
Search migrated product descriptions, collection descriptions, blog posts, navigation and theme files for absolute links and image sources still pointing at the old domain or old CMS media paths, and repoint them at the new store or Shopify Files. Why: Imported descriptions keep pulling images from the old library, so product pages lose their images the day the old host is switched off. Only when: migrating from an existing store. Moving platforms
Every product and category meant to be live is in the sitemap, and no sitemap address is broken, redirected or hidden from search. Why: Products created by CSV import often arrive unpublished, so they look correct in admin while being invisible to shoppers and crawlers. Core list
With all apps installed, validate Product structured data on a simple product, a product with variants, a discounted product and a sold out product, including ?variant= URLs, and confirm each page outputs exactly one Product block whose price, currency and availability match what the page shows after a variant is selected. Why: Review and SEO apps inject a second Product block and variant markup often stays frozen to the first variant, which gets listings disapproved. Catalogue and search Shopify
Before the DNS switch, export and date a baseline containing 12 months of Search Console queries and pages, current positions for the top 50 keywords, and organic sessions for the top 100 landing pages, then keep access to the old Search Console property after launch and file a Change of Address if the domain changed. Why: Without a dated baseline a seasonal dip and a migration mistake look identical, Search Console keeps only 16 months, and the old property is the only place the 404 spike appears after launch. Only when: migrating from an existing store. Moving platforms
The old store's addresses that had visits or links in the last year are saved before the build, and after launch each one opens, or redirects in one step, to its matching page, not to the home page. Why: Bulk redirect imports drop rows without warning and mistyped targets fail quietly, so breakage stays invisible until the traffic is gone. An old address sent to the home page tends to be treated by search engines as a missing page, so each one goes to the page that replaces it. Addresses nobody visited or linked to in a year are left out, which keeps the list one that can be checked line by line. Core list
Every other form of the store's address (http, www, platform or staging) redirects to the main one or is switched off. Why: When the same pages open at more than one address, Google picks one of them to show in its results, and it may not be the one you chose. Core list
Nothing left over from development hides the live store from search engines: no password page and no leftover blocking setting. Why: A global noindex left on in an SEO app makes Google drop each page from its results once it crawls it, and a leftover Disallow line stops Google reading the pages. Core list
The live site is verified in Google Search Console under your own account, and its sitemap is submitted. Why: A store nobody verified has no report of crawl errors, so an indexing problem after launch goes unseen. Core list
Recrawl the store on day 1, day 7 and day 30 of the 30 day included post-launch window, check the Search Console Pages report for new Not found and Page with redirect entries, compare the top 20 landing pages against the dated baseline, and record in the project doc the drop that triggers investigation, for example one page down more than 30 percent for seven days running, together with who watches for that drop once the window closes on day 30. Why: Migration damage builds gradually, and with no fixed dates and no written trigger it is spotted months later. 30 days after

Machine-readable content and AI assistants 10 checks

Record the client's written allow or block decision for each named AI crawler (GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended, CCBot, Bytespider) in the project doc before any robots.txt change is made. Why: Otherwise someone blocks every AI user agent as a precaution, or nothing is blocked and the client finds out after launch. Catalogue and search
Agree the ten questions the support team answers most often before purchase and confirm each appears on a crawlable URL as a heading in question form with the answer in plain text directly below it, not inside a chat widget or a JavaScript accordion. Why: Answers that live only inside a chat script cannot be pulled out of the page by anything. Design and message
Publish robots.txt.liquid on the live theme and confirm the production /robots.txt returns the agreed AI crawler rules exactly as recorded. Why: Robots rules get edited on an unpublished theme copy, so the agreed rules never reach production. Catalogue and search Shopify
Populate brand, sku and gtin in Product markup from the Shopify barcode field, and leave gtin out entirely for products with no real barcode instead of pasting the SKU into it. Why: An SKU in the gtin field is an invalid identifier, so the product cannot be matched to the same product listed elsewhere. Catalogue and search Shopify
Publish Organization markup on the homepage with legal name, logo URL, site URL and sameAs profile links, and confirm the same brand string appears in the brand field of Product markup, in the footer and on the contact page. Why: A company name written three ways gets merged with a similarly named business or quoted under a name customers cannot find. Catalogue and search
Store product specs (materials, dimensions with units, weight, box contents, compatibility, care) in metafields and render them as text on the product page, checked on three products from different product types. Why: Specs buried in a description image or a PDF are skipped for fit, materials and compatibility questions. Catalogue and search Shopify
Confirm aggregateRating markup appears only on products with published reviews and that ratingCount matches the number of reviews visible on that page, checked on one product with reviews and one without. Why: Review apps emit rating blocks for products with zero reviews, which makes the markup invalid and discounts the whole Product block. Catalogue and search
Request the home, collection and product templates on the production domain with the GPTBot, OAI-SearchBot, ClaudeBot and PerplexityBot user agent strings and confirm each returns HTTP 200 with the full HTML body. Why: A bot protection layer or block bad bots app answers everything except Googlebot with a 403, so the store is invisible to AI crawlers. Catalogue and search
Load the product template with JavaScript disabled and confirm title, price, currency, stock state and the full description are present in the initial HTML response. Why: Themes that fetch price and description after load serve an empty shell, so the product reads as having no price. Catalogue and search
Re-run the structured data validation and the JavaScript-disabled product page check on day 30, the last day of the included post-launch window, and send the client the logged result. Why: After handover a new review or upsell app adds a second Product node or moves the price into a script. 30 days after

Access for everyone 13 checks, 1 in the core list

Record in the project brief that the store is built to the accessibility checks in this list, that this is not a WCAG audit, and whether the client has taken advice on the European Accessibility Act. Why: With nothing written down there is nothing on record showing what the store was built against, and saying plainly that this is not an audit keeps a list of checks from being read as a certificate. Speed and access
Check every text and interface colour against the background it actually sits on, 4.5:1 for body text and 3:1 for large text, icons and control borders, covering sale prices, stock badges, placeholder text, disabled sold out buttons, text over hero photography and the colours set in checkout branding. Why: Palettes are approved on white artboards, then the sale price red lands on a photograph and becomes the least readable thing on the page. Speed and access
Build variant selectors as real radio inputs or buttons that take keyboard focus and expose their checked state, hidden with a visually hidden class rather than display:none or visibility:hidden. Why: Swatches rendered as divs let a keyboard user reach add to cart but never choose a size, so no order is possible. Speed and access Shopify
Confirm every focusable element in the browse and buy path shows a focus indicator with at least 3:1 contrast against the colour behind it, that no site wide outline:none rule ships, and that indicators are not clipped by overflow:hidden on carousels, sticky headers or the cart drawer. Why: Someone asks for the blue ring to be removed, a developer kills it globally, and reaching checkout becomes guesswork. Speed and access
Verify that opening the cart drawer, search overlay, quick view and any popup moves focus into it, keeps Tab cycling inside it, closes on Escape, returns focus to the control that opened it, and marks the rest of the page inert or aria-hidden. Why: Most themes leave focus behind the overlay, so a screen reader user is never told the cart drawer opened. Speed and access Shopify
Announce every cart change through a polite live region that is already in the DOM before the update, covering add to cart, quantity change, line removal, discount code result and stock limit errors, with wording that names the item and the new cart count. Why: An AJAX add to cart only repaints the bubble, so a screen reader user presses again and ends up with three of the same item. Speed and access Shopify
Update a live region with the new result count after every filter, sort and load more action on collection and search pages, keep focus on the control the shopper used, and move focus to the first newly added product when more products are appended. Why: Faceted filters swap the grid silently, so the shopper cannot tell whether four or four hundred products came back. Speed and access Shopify
On every form the theme owns, give each input a visible label tied to it programmatically instead of a placeholder, set the correct autocomplete token on name, email, phone, address, city, postal code and country fields, and tie each error message to its field with aria-describedby and aria-invalid, moving focus to the first field in error on submit. Why: Placeholder-only address fields force anyone using autofill to retype the address, and an unfocused error summary hides which field is wrong. Speed and access
Give every icon only control an accessible name, including cart, search, account, wishlist, quantity plus and minus, gallery arrows, close buttons and quick add, and make quick add names product specific, for example Add Linen Shirt to cart. Why: A 48 product collection otherwise reads out as button, button, button with nothing to say which product each one belongs to. Speed and access Shopify
Set one alt text rule for the store (gallery images describe the view and the variant shown, decorative images carry an empty alt attribute, no alt text is a filename or keyword list), confirm the templates follow it and apply it to the agreed sample of products, and list for the client the content that exists only inside an image, such as size charts, ingredient tables and care instructions; the rest of the catalogue is quoted by product count. Why: Shopify falls back to the uploaded filename when alt is blank, and a size chart saved as a JPEG leaves nobody able to find their size. Catalogue and search Shopify
Test the home, collection, product and cart templates at 200 percent browser zoom with no content cut off, and confirm the viewport meta tag does not set user-scalable=no or maximum-scale=1. Why: Sticky headers and buy bars stack up at high zoom and cover the buy button, and blocked pinch zoom hides the price. Speed and access
Open every third party embed on the live theme, including email capture popups, review widgets, consent banners, subscription selectors and chat launchers, test whether each one can be reached, operated and dismissed with the keyboard alone and closes on Escape, and report every embed that fails to the client with its vendor named, since that code is the vendor's to fix. Why: These apps are installed after the theme is signed off, and one focus-stealing popup stops a keyboard user getting past the homepage. Speed and access Shopify
One purchase is completed using only the keyboard, and every blocker found is fixed or written down. Why: Automated scans pass on pages where focus order is scrambled, so the failures that stop an order surface only when someone places one. Core list

Payments, shipping, tax and discounts 14 checks, 7 in the core list

Payment is taken at purchase or held for approval, as agreed, and if held, the handover document names who approves. Why: Manual capture with nobody assigned lets authorizations expire, so you ship orders that were never charged. Core list
Tax settings (prices with or without tax, tax on shipping, tax per product type) follow written instruction from you or your accountant. Why: A shopper in a tax inclusive market who watches the price jump at checkout abandons, and wrong tax is corrected order by order later. Core list
Confirm only locations that can actually ship online orders are enabled for the online store and that stock sits at those locations. Why: Stock held at a location not enabled for online fulfilment makes the whole catalogue read sold out on launch day. Connected systems Shopify
Only the payment methods you agreed to are switched on, with test mode off and no test gateway left behind. Why: Test mode left on accepts orders that never charge a card, and a leftover cash on delivery method lets buyers check out without paying. Core list
A real card order is placed and refunded on the live store through each payment provider, and both appear in its report. Why: Credentials that pass the admin connection check still fail on the first live charge when the merchant account is unverified. Core list
A declined card and a card needing a bank check are tried: the cart survives and no order or double charge results, or the platform's own behaviour is written down. Why: A declined payment leaves no paid order behind, so a checkout that drops the cart on a challenge passes every successful-order test. Where the checkout is the platform's, what it does is recorded, since it is not ours to change. Core list
A real order is placed and refunded on a phone through each express button switched on, such as Apple Pay or PayPal. Why: Express buttons skip the cart and use their own address and shipping steps, so a wallet that looks live but fails is found by the first real customer. Core list
Every country you sell to is inside a shipping zone, and a test checkout in each zone shows a working rate. Why: A weight bracket that stops short shows a no shipping methods available message and a checkout the shopper cannot finish. Core list
Where the cart shows a free shipping progress bar, confirm it uses the same basis as the shipping rate condition (before or after discounts, with or without tax) by placing one order just under the threshold and one just over it. Why: The bar says shipping is now free and checkout then adds a charge, which shows up as abandoned carts and refund requests. Design and message
For each active market, confirm the currency, rounding rule and any price adjustment match the pricing agreed in writing, confirm every product meant to sell there is published to that market's catalogue, place one test order in that market's own currency, and where the store serves more than one domain confirm Apple Pay appears on each of them. Why: A market with no rounding rule prices items at 19.37, and a product left out of a market's catalogue returns a 404 from search. Only when: selling in more than one country or currency. Catalogue and search Shopify
Test every discount that will be live at launch against every automatic discount running at the same time and against the free shipping threshold, and compare the resulting order totals to the amounts agreed in writing. Why: A code that stacks with an automatic discount ships orders at a total nobody approved, usually found at the first payout. Catalogue and search
Buy one gift card on the live store and confirm that checkout asks for no shipping address, the recipient email arrives with a working code, any scheduled send date is respected, and the code redeems on a second test order. Why: A gift card built as a physical product forces a shipping charge, and an untested delivery email means the recipient never gets the code. Only when: the store sells gift cards or store credit. Catalogue and search Shopify
Confirm exactly one abandoned checkout sequence is active across Shopify's built in recovery emails and any marketing app, verified by abandoning a real checkout and logging every message received over the next 48 hours. Why: Two sequences send the same shopper two codes, and the larger discount gets used on an order that was already coming back. Connected systems
If a subscription app is in scope, place one subscription order, force the next billing cycle in the app, and confirm the renewal charge, the renewal email, the customer portal actions (pause, skip, cancel) and the failed payment retry rules all work, and that a cart mixing a subscription item with a one time item completes checkout. Why: Renewals fail quietly on a gateway that cannot store the card, and with no working portal every pause becomes a support email. Only when: the store sells subscriptions. Connected systems Shopify

Catalogue and content quality 13 checks, 3 in the core list

Bringing existing customers and their balances across 4 checks

Import customer records with their marketing consent state, confirm the subscribed count in the new store and in the email platform matches the old platform's export, and record in the handover doc whether past orders were migrated, what a returning customer has to do to log in, and the approved message telling them their old password does not carry over. Why: Repeat customers are the cheapest revenue the client has, and a list imported as unsubscribed loses the email channel. Only when: migrating from an existing store. Moving platforms
Recreate every unspent gift card and store credit balance from the old platform, reconcile the number of active codes and their total value against the export, then redeem one migrated gift card and one migrated credit balance on test orders and confirm the remaining balance is correct. Why: These are debts the client already collected cash against, and a card that fails at checkout is paid out twice. Only when: migrating from an existing store. Moving platforms
Record which customer accounts version the store uses, new customer accounts or classic, log in as a migrated customer through that route, confirm order history, saved addresses and reorder work, and confirm every app that depends on accounts (wishlist, loyalty, subscriptions) supports that version. Why: The two versions behave differently and several app categories support only one, which means rebuilding a bought feature. Moving platforms Shopify
Import the old email platform's unsubscribe, complaint and hard bounce suppression list into the platform the client has chosen before any send, reconcile the imported count against the export, and send one campaign to a test segment confirming suppressed addresses are excluded. Why: Emailing people who already opted out is a legal exposure and damages the sending domain before the first big campaign. Only when: migrating from an existing store. Moving platforms

Order emails from your own domain 3 checks, 2 in the core list

Order emails are signed as coming from your domain where the platform allows, test-sent to Gmail, Outlook and iCloud Mail, and where each landed is recorded. Why: Unsigned confirmations are the ones that get filed as spam, which turns straight into did my order go through tickets and duplicate orders. The records that sign them (SPF, DKIM and DMARC) live in your domain's settings rather than in the email tool, and where a message lands is the mailbox provider's decision, so the check records it instead of promising it. Some platforms cannot send from your own domain; the check then records what the platform allows. Core list
Every order, shipping and account email the store sends carries your logo, name and support address and no placeholder text, and replies reach a monitored inbox. Why: Order confirmations are among the emails customers open most, and one naming the dev store produces support load from day one. Core list
List every transactional message (order confirmation, shipping, delivery, refund, back in stock) and confirm exactly one system sends each one, with the duplicate switched off in either Shopify notifications or the email platform. Why: Overlapping setups send two confirmations with different totals, or none at all when each side assumes the other owns it. Connected systems Shopify

Orders, stock and connected systems 13 checks, 1 in the core list

Send a webhook payload with an invalid X-Shopify-Hmac-Sha256 signature to every automation endpoint and confirm it is rejected with a 4xx response and that no downstream record is created. Why: An unverified webhook URL is a public endpoint, so anyone who finds it can inject fake orders into the fulfilment chain. Connected systems Shopify
Confirm every Shopify webhook endpoint returns 2xx in under five seconds and does its processing after the response, checked against the endpoint's own response time log. Why: Shopify treats a slow response as a failure and eventually removes the subscription, so orders stop arriving with nothing visibly broken. Only when: a 3PL, ERP or other outside system exchanges order or stock data with the store. Connected systems Shopify
Deliver the same order webhook twice into every automation and confirm exactly one downstream record exists afterwards: one 3PL order, one email platform event, one accounting entry. Why: Shopify delivers at least once and repeats after any timeout, so without an idempotency key the warehouse ships twice. Only when: a 3PL, ERP or other outside system exchanges order or stock data with the store. Connected systems Shopify
Confirm every failed order, inventory or fulfilment run is stored with its full payload and error text, and replay one stored failure end to end without editing any data by hand. Why: When the 3PL API errors for two hours overnight, those orders can be reprocessed instead of existing as a log line. Only when: a 3PL, ERP or other outside system exchanges order or stock data with the store. Connected systems
Run a full-catalogue inventory and price sync and confirm every SKU in the source file ends with the intended value in Shopify, with the run backing off and retrying on 429 responses instead of skipping records. Why: Shopify throttles bulk writes part way through, and a run with no backoff drops the remaining SKUs silently. Connected systems Shopify
Run the inventory sync against a product stocked at more than one Shopify location, place an order for it mid-sync, and confirm the sync writes to the intended location and does not restore the count the order just reduced. Why: Writing to the wrong location sells items the warehouse cannot ship, and the customer only finds out after paying. Only when: a 3PL, ERP or other outside system exchanges order or stock data with the store. Connected systems Shopify
An awkward test order (two items, a discount, a second address line, non-Latin letters) arrives complete where orders are packed. Why: Field mapping breaks on the second address line or accented characters, and engraving text missing from the packer's paperwork ships as wrong goods. Core list
Fulfil a test order in the 3PL and confirm it writes back to Shopify with tracking number and carrier attached and that the shipping confirmation email sends. Why: Without write-back the warehouse ships while Shopify shows the order unfulfilled, so no tracking email goes out. Only when: a 3PL, ERP or other outside system exchanges order or stock data with the store. Connected systems Shopify
Place one test checkout with the marketing opt-in ticked and one with it unticked, and confirm the email platform shows the first profile as subscribed, the second as not subscribed, and that the second enters no marketing flow. Why: Emailing people who never opted in produces spam complaints that cut delivery for every campaign after it. Connected systems
Complete a checkout part way through an abandoned cart sequence and refund a second test order inside the post-purchase sequence, then confirm both profiles stop receiving the remaining emails in those sequences. Why: A customer who already paid full price receives a recovery code and asks for the difference back. Connected systems
Cancel a test order in Shopify before it ships and confirm the cancellation reaches the 3PL and the fulfilment request is stopped there, not only marked cancelled in Shopify admin. Why: Otherwise the warehouse ships and charges for an order the customer already cancelled. Only when: a 3PL, ERP or other outside system exchanges order or stock data with the store. Connected systems
Confirm a daily digest reaches Slack or email with orders received, orders synced downstream, failed runs, and anything unsynced for more than an hour, and that it still sends when the order count is zero. Why: An integration that stops completely produces no error at all, so silence looks exactly like a quiet sales day. Connected systems
For the first two weeks of the 30 day included post-launch window, compare the daily Shopify order count against the counts in the 3PL and accounting systems' own reports rather than the automation's logs, confirm the numbers match, and name in the handover note the person on the client's side who runs the same comparison after the window ends. Why: Slow leaks show up as one missing order in two hundred, which only a count comparison finds. Only when: a 3PL, ERP or other outside system exchanges order or stock data with the store. Connected systems

What happens after someone orders 4 checks, 3 in the core list

Every contact form on the live store is tested, and each message reaches a mailbox your team reads and can answer. Why: A form pointing at a mailbox nobody opens swallows pre-purchase questions and return requests for months. Core list
A test order is followed as a customer would, from confirmation email to tracking to the returns route, and each step works. Why: Where is my order and how do I return this are among the most common support messages a store gets. Core list
Where customer accounts are switched on, a new customer can sign up, sign in and reset a password on the live store. Why: A sign-up or reset email that never arrives locks a customer out of their orders, and you hear about it as a support message or a lost order. Where the platform signs customers in with an emailed code and no password, the reset step is marked not needed. Core list
Confirm Shopify self serve returns is either switched on and tested with one return request that reaches the fulfilment team, or switched off deliberately with the manual return process, the return address and the named owner written in the handover doc. Why: Publishing a return policy with no tested route to act on it leaves the client refunding by hand in week one. Connected systems Shopify

Measurement and ad platforms 19 checks, 1 in the core list

Before build starts, write a measurement plan the client approves in writing that lists every event to be tracked, the parameters each event carries, the platforms each event is sent to, the rule for whether reported order value includes tax, shipping and discounts, and the named owner of each analytics and ad account. Why: Tracking built without an agreed spec produces numbers the client and their media buyer argue about. Tracking and ads
Confirm in GA4 DebugView that view_item, add_to_cart, view_cart, begin_checkout, add_payment_info and purchase each fire once with item_id, item_name, price, quantity and currency populated from real product data. Why: Shopify's default connection reports sessions and orders but nothing in between, so nobody can see where checkout loses people. Tracking and ads
Confirm add_to_cart fires exactly once from every place a product can be added: the product page form, quick add buttons on collection cards, the quick view modal, cart drawer upsells and any bundle or subscription widget. Why: Quick add posts over AJAX and never reaches the theme's form handler, so collection pages record no cart activity. Tracking and ads Shopify
Run all checkout and thank you page tracking through Customer Events custom pixels, with no tracking code left in checkout.liquid, Additional Scripts or order status page scripts. Why: Shopify is retiring those surfaces, so a store depending on them stops recording purchases with no error anywhere. Tracking and ads Shopify
Pick one product identifier, variant ID or SKU, record it in the project doc as the single item_id for the store, and confirm the GA4 ecommerce events and the Shopify product feed both carry that same value for five sample products. Why: With no single recorded identifier every downstream feed picks its own, and nothing can be matched back to a product later. Only when: the client runs Google or Meta shopping ads. Tracking and ads
Take Google Ads purchase conversions from one source only, either imported GA4 key events or the Google Ads conversion tag, and set conversion counting to one per order, then place one real order and confirm it is counted once in Google Ads and in Meta where the client has granted access, recording in the handover note which platforms were checked and which were left to the client. Why: Running both records every sale twice, so smart bidding pays up to double the target cost for the same revenue. Only when: the client runs Google or Meta shopping ads. Tracking and ads
Add every wallet and payment domain the checkout touches to the GA4 unwanted referrals list, including paypal.com and shop.app, then place a test order through PayPal and confirm the session keeps its original source. Why: Otherwise paid and email orders get filed under referral traffic and campaigns that work look unprofitable. Tracking and ads Shopify
Test tracking in both states of Shopify's Customer Privacy API: with consent denied no analytics or advertising cookies are set and consent mode sends ad_user_data and ad_personalization as denied, and with consent granted add_to_cart and purchase fire as normal, then send the client the list of installed apps with the cookies each one sets, to compare with the privacy page, which the client or their adviser confirms. Why: A consent banner added late blocks the pixel outright, so European traffic disappears from reporting until month end. Tracking and ads Shopify
Set the GA4 property currency and timezone to match the store's, and raise event data retention from the two month default to 14 months. Why: A currency mismatch reports revenue the client never took, and default retention deletes the data before any year on year view. Tracking and ads
One real order on the live store is recorded exactly once in analytics, with the right order number, currency and value. Why: Broken value mapping sends 0.00 or one line item price, and a leftover pixel quietly doubles the same order. Core list
Exclude the client's and the agency's IP addresses as internal traffic in GA4, then confirm that orders placed through Shopify's Bogus Gateway do not appear as purchases in the reporting property. Why: Test orders are real purchase events with real values, so ad platforms train their bidding on fake conversions. Tracking and ads Shopify
Export and date a commercial baseline from the client's existing analytics before cutover covering 12 months of sessions, conversion rate, average order value and revenue split by channel and by device, stored where the client can open it without asking the agency. Why: After cutover the old reporting is often switched off, so the baseline has to be captured while it still exists. Tracking and ads
Where the client has granted Google Merchant Center and Meta commerce account access, confirm within 24 hours of the domain going live that the live domain is still claimed and verified, re-fetch every product feed, and confirm the disapproved item count is no higher than before launch and that five sample item URLs each return 200 with no redirect, and where access has not been granted send the client a written note on launch day listing these same checks as theirs to run that day. Why: Domain claims and feed URLs break at cutover, and a mass disapproval stops shopping sales while the ad budget keeps running. Only when: the client runs Google or Meta shopping ads. Tracking and ads
Where the client grants Google Merchant Center and Meta catalogue access, which the agency requests after launch and inside the 30 day included post-launch window, confirm the recorded item_id matches for the same five sample products in both catalogues, and where access is not granted write the recorded item_id and this check into the handover note for whoever runs the client's advertising. Why: Mismatched IDs give dynamic remarketing nothing to match, and ad account access usually sits with the client's own media buyer rather than the agency. Only when: the client runs Google or Meta shopping ads. Tracking and ads
Where the client grants Meta Events Manager and Conversions API access, which the agency requests after launch and inside the 30 day included post-launch window, send the same event_id from the browser pixel and the Conversions API for purchase and confirm Events Manager reports the events as deduplicated, and where access is not granted write in the handover note that Meta purchase events are browser side only and undeduplicated. Why: Without a shared ID Meta counts each order twice and reported ROAS is close to double the real figure, so the client needs it stated plainly when the work sits outside the agency's access. Only when: the client runs Google or Meta shopping ads. Tracking and ads
Reconcile the first seven full days of GA4 purchases and revenue against Shopify's order reports, inside the 30 day included post-launch window, and document in writing what explains any difference above five percent. Why: GA4 and Shopify never match exactly, and an unexplained gap makes the client distrust the whole setup. Tracking and ads Shopify
Set a GA4 custom insight that emails both the agency and the client when daily purchases fall below an agreed threshold, and write in the handover note that the agency acts on that alert for the 30 days of the included window, after which the client owns the response. Why: Tracking breaks silently after a theme edit, and without an alert and a named owner the gap is found weeks later. 30 days after
On day 30, the closing day of the included post-launch window, place sessions, conversion rate and average order value from the new store next to the dated baseline and send the client a written note naming every channel and device below it, with what is being checked for each one and who carries that check on now the window has closed. Why: A month covers a full promotional and email cycle, and whether the store still sells is the first question the client asks. Tracking and ads
Hand over one dashboard showing revenue, orders, conversion rate and revenue by channel, plus a recorded walkthrough that names the source of each number on it, both delivered inside the 30 day included post-launch window. Why: A dashboard nobody was shown is never opened, so the client keeps comparing Meta's self reported revenue with Shopify totals. Tracking and ads

Launch day 11 checks, 6 in the core list

Lower the TTL on the apex and www records to 300 seconds at least 24 hours before cutover, using the registrar or DNS host login the team will use on launch day, and confirm the new value with a public DNS lookup. Why: A 24 hour TTL keeps a wrong record cached for a full day, and doing this early proves someone can actually change DNS. Moving platforms
Using the DNS access requested as standard at the start of the project, export the full DNS zone before cutover and list every record that is not the storefront A or CNAME record, including MX, SPF, DKIM, DMARC, domain verification TXT records and any subdomain used for mail, help desk or tracking. Why: Registrar interfaces make it easy to replace records rather than add to them, and mail records are the ones that get dropped. Moving platforms
Agree the rollback in writing before cutover, naming the failures that trigger it, the person who decides, the maximum time allowed to decide and the original DNS values to restore, and keep the old platform reachable at a temporary hostname with hosting and licences paid for at least 30 days, checked by loading one product page on day 1 and day 7. Why: A theme rollback only reverses theme changes, and the route back to the old system closes the moment hosting lapses. Only when: migrating from an existing store. Moving platforms
We give your team a written script for the buy path; named people on your team run it before launch, and each problem is fixed or accepted in writing. Why: Every other test is us checking our own work, so without this there is no moment where you accept the build. Core list
The launch runs from a written plan with a named owner for each step and a way back, outside your busiest hours and campaigns. Why: Improvised cutovers skip steps under pressure, and launching during a promotion puts the busiest hours inside the riskiest window. The way back is the saved copy from the version check and the written steps in the handover document. Core list
Stop the old platform taking new orders inside the cutover window, prove it by attempting one checkout on the old store's own address, and record in the handover doc who keeps admin access there, until what date, and who issues refunds and handles returns for orders placed before launch. Why: DNS propagation keeps the old store selling into an admin nobody watches, and its trailing order book needs a named owner. Only when: migrating from an existing store. Moving platforms
After the old store stops selling, re-export inventory and prices from the system that owns them, import them into the new store, and confirm the on hand count matches the source for every SKU with fewer than ten units and for the twenty best sellers, recording the export timestamp and the number of SKUs corrected. Why: Catalogue data imported weeks earlier has drifted, so launching on stale counts oversells the fastest selling products. Only when: migrating from an existing store. Moving platforms
If launch changes where your domain points (its DNS records), the old ones are saved first, then checked after, and a test email is sent and received. Why: A switch that drops the mail record stops your company email, including the inbox your customers reply to. Core list
The live store opens securely (HTTPS) on the main address, the www address and a product page, with no browser warning. Why: The certificate is issued once your domain's records point to the platform, and on Shopify that can take up to 48 hours, so a store that looks live can show a security warning until then. Core list
Straight after launch, a real paid order is placed on the live domain from a phone, checked end to end, and refunded. Why: Checkout behaves differently on the live domain than in preview, and a gateway left in test mode loses every real order. Core list
Within an hour of launch, page views, add to cart and purchase are recorded in your live analytics, not a development copy. Why: Development IDs survive the move more often than anyone expects, so launch week lands in a test property or nowhere. Core list

Ownership, handover and life after launch 13 checks, 11 in the core list

No password or secret key is left in the store's code or in the page source. Why: Keys pasted into a theme file during build stay in the published theme and are readable by anyone who views source. Core list
The store's owner account, domain, subscriptions and billing card are in your name, and we hold only a login you can remove. Why: A store or a domain registered to an agency's account is hard for you to get back if the relationship ends. Core list
A copy of the launched code is kept in your own repository (for example GitHub), or in a named backup where the platform keeps no code. Why: When the code exists only in the platform's admin, one overwritten section is gone for good. The launch is tagged in the repository so it can be found again. Core list
Before the new version goes live, the one live now is saved as a dated copy that can be put back. Why: Without a saved copy a broken launch has nothing to put back within minutes. On Shopify, for one, a theme you replace is kept as a draft, but edits to the live theme itself can be undone only one file at a time. Core list
Products, categories, customers, discount codes and redirects are exported to files kept where you can reach them without asking us. Why: A bad bulk edit can overwrite thousands of records, and most platforms offer no undo for catalogue data. Core list
Logins with access to orders or the store are reviewed against who still needs them, two-step sign-in is on, and access keys are listed. Why: Build projects leave standing keys and freelancer logins with access to orders and customer data for years. Core list
Have the client's named editor, not an agency person, complete five tasks in the theme editor while the team watches: change the homepage hero image and headline, switch the promotion bar on and off, add a product to a menu, publish a new collection page, and update the free shipping threshold text. Anything that needed developer help is either rebuilt as an editable setting or listed in the handover doc as work for a developer, before launch. Why: Content hardcoded in Liquid turns every sale and campaign into an invoice, which the client discovers in month two. Design and message Shopify
Set up a hosted third party uptime service, not a monitor built by the agency or hosted with the store, to request the homepage, one product page and the cart or checkout entry at least every five minutes, name in the handover note the person at the agency and the person at the client who receive every alert, confirm the alert reaches both by triggering a test failure, give the client a separate direct channel with a phone number for the store being unreachable or checkout failing during those 30 days, and state the date the agency stops watching it, 30 days after launch, when the client's own account carries it on. Why: A monitor that shares infrastructure with the store goes down silently with it, an alert with nobody named against it is never answered, and a dead checkout should not wait its turn in a ticket queue. 30 days after
For seven days after launch, orders, failed payments and broken pages are checked daily, and each issue is fixed or reported to you by day 30. Why: The first week surfaces what no test catches, and an issue nobody wrote down falls between you and us. The day 1, 7 and 30 recrawls belong to the 30 days after pack, and the abandoned checkout emails are tested in the Connected systems pack. Core list
You get a recorded walkthrough, as a file and a link, of editing each custom section, adding a product, publishing and going back. Why: What is obvious to whoever built the store is not obvious to your team, so the store stops being updated. Core list
A written handover document lists every app and its monthly cost, every outside account and owner, where the code lives and how to roll back. Why: Undocumented apps keep charging for tools nobody remembers, and the next developer rebuilds code they cannot find. Core list
Every account opened during the build, such as analytics, the email platform and review tools, has your email as owner by day 30. Why: An account under an agency's email becomes unreachable to you when the work ends, and its history goes with it. Core list
A support note you confirm by reply sets the 30 days of fixes, one reporting channel, a one-business-day first reply and what counts as a defect. Why: Without a written window and a business day clock, every request after launch is negotiated one by one. Core list

Book 15 minutes with Anthony.

Find out what your store is costing you. A 15-minute call, then written notes. Yours either way.

Book a 15-minute store review or email hello@craftive.dev