How this differs from the general ecommerce launch checklist

If you haven't already, Ecommerce Business Launch Checklist covers the broader, business-formation-inclusive readiness pass (entity registration, bank account, tax setup, general listing and fulfillment readiness) that applies whether you're launching on a marketplace, a DTC website, or both. This checklist is a companion to that one, not a replacement for it — it's deliberately narrower and store-build-tactical: the specific technical and on-site work of getting a DTC storefront itself ready to go live, assuming the underlying business readiness is already handled or in progress in parallel.

Domain, DNS, and SSL

  • Custom domain purchased and connected to your storefront (not just the platform's default subdomain).
  • DNS records correctly pointed and fully propagated — verify from more than one network/location, since propagation can appear complete on one connection while still lagging elsewhere.
  • SSL certificate active and the site loading over HTTPS everywhere, with no mixed-content warnings on any page (a common cause: an image, script, or embed still referencing an old http:// URL).
  • Any old domain or subdomain properly redirected, if you're migrating from a previous site, rather than left as a dead or conflicting destination.

Payment gateway test transactions

  • At least one real test transaction run through every payment method you offer (major card networks, and each express/wallet option — see DTC Checkout Optimization and Cart Abandonment for why offering several matters), confirmed to actually complete and appear correctly in your payment processor's dashboard.
  • Refund process tested at least once, since a failure in refund processing is far worse to discover from a real, upset customer than from a test transaction.
  • Payout/settlement account confirmed correctly connected, so revenue actually reaches your business bank account on the expected schedule.

Tax and shipping zone configuration

  • Sales tax collection configured for every jurisdiction where you have a legal obligation to collect it, reflecting your current registration status (this connects to your broader business/tax setup — consult a tax advisor on where you actually have obligations if you haven't already, since requirements vary by state/country and by how much you sell there).
  • Shipping zones and rates configured to match your actual fulfillment capability — don't leave a zone open for order acceptance that you can't actually ship to yet, or leave rates at a platform default that doesn't reflect your real carrier costs.
  • International shipping either properly configured (duties/customs handling decided and communicated) or explicitly disabled, rather than left ambiguous and discovered mid-order.
  • Privacy policy, terms of service, and return/refund policy published, linked from the footer, and accurate to your actual practices — see Return, Refund, and Privacy Policy Templates for what each should actually cover and the sections most often missing from a copied template.
  • Return/refund policy specifically also linked from or near the product page and checkout, not just the footer, since that's where a hesitant buyer is most likely to look for it before purchasing.
  • Cookie/tracking disclosure in place if you have relevant traffic (EU visitors, for example) requiring it.

Tracking pixels installed and verified

  • Analytics and ad platform tracking pixels (Meta, Google, TikTok, and any others relevant to your planned advertising) installed and, critically, verified as actually firing correctly on the events that matter (page view, add-to-cart, purchase) — an installed-but-misconfigured pixel is functionally the same as no pixel at all once you start spending on ads against bad data. A dedicated companion guide, Setting Up Analytics and Tracking for a DTC Store, covers this in full depth; treat this checklist item as the reminder to actually complete and verify that setup before launch, not a substitute for it.
  • Server-side or conversion-API tracking configured where the platform/ad channel supports it, in addition to browser-based pixels, since browser-based tracking alone has become measurably less reliable due to browser privacy changes and ad blockers.
  • A real test purchase (even a low-value one, refunded afterward) used to confirm the purchase event fires with the correct order value, not just that the pixel loads on the page.

Mobile QA pass

  • Full checkout flow completed successfully on at least one real mobile device, not only in a desktop browser's mobile-simulation view.
  • Key pages (homepage, a product page, cart, checkout) reviewed on a real phone for layout issues, oversized or cut-off elements, and tap targets that are difficult to hit accurately.
  • Page-load speed checked on a mobile connection specifically, since mobile networks and devices are typically slower than the desktop/office wifi environment most pre-launch QA happens on.
  • Every navigation link, footer link, and any hardcoded internal link across the site (including within homepage banners or promotional sections) clicked through at least once, since a broken link found by a paying customer reads as carelessness in a way it doesn't when caught internally.
  • A custom, on-brand 404 page in place for any URL that is genuinely missing, ideally with navigation back into the site rather than a dead end.
  • External links (social profiles, any partner or press mentions) checked too, not only internal site links.

Staging vs. live discipline

  • A staging or preview environment used for pre-launch changes rather than editing the live, publicly-accessible storefront directly — most platforms offer some form of this, and using it consistently avoids a half-finished change being visible to real visitors mid-edit.
  • A clear, agreed process for who can publish changes directly to the live store post-launch, and under what circumstances a change should go through staging/review first rather than being pushed live immediately — this matters more once more than one person has store access.
  • A basic rollback plan (theme version history, a recent backup/export) confirmed to exist and actually work, before you need it under pressure.

Soft launch vs. public launch

Consider a soft launch — a period of limited, low-visibility traffic (a small paid test budget, an email to an existing list, or simply not yet promoting the site widely) before a full public launch push. This surfaces checkout, tracking, and fulfillment issues against real (if limited) order volume while the cost of a mistake is still small, rather than discovering the same issues for the first time during a larger, harder-to-recover-from launch campaign. A soft launch is optional, not mandatory — for a very simple store or a founder confident in the technical setup, moving straight to public launch is a reasonable choice — but for a first DTC launch specifically, the modest delay is usually worth the risk reduction.

Common mistakes

  • Launching ad campaigns before verifying tracking pixels actually fire correctly, spending real ad budget against data you later discover was broken or incomplete.
  • Skipping a real test transaction for every payment method, discovering a broken express-payment option only when a real customer's order fails.
  • Leaving a shipping zone open for jurisdictions you can't actually fulfill to yet, or leaving default shipping rates in place that don't reflect real carrier costs.
  • Doing all pre-launch QA on desktop only, missing mobile-specific layout, speed, or checkout issues that a majority of visitors will actually encounter first.
  • Skipping a soft launch entirely for a genuinely new, untested setup, discovering fixable issues only after a large public launch push has already sent significant traffic and spend at the store.

Best practices

  • Treat tracking-pixel verification (not just installation) as a hard launch blocker, since bad tracking data undermines every advertising decision made afterward.
  • Run at least one real, low-value test transaction through every payment method before launch, refunding it afterward.
  • Do the mobile QA pass on an actual physical device, not only a browser's simulated mobile view.
  • Use a staging environment for pre-launch changes rather than editing the live site directly, and confirm a rollback path exists before you need it.
  • Consider a soft launch with limited traffic to surface real-world issues before committing to a larger public launch push.

FAQ

Do I need a soft launch, or can I go straight to a full public launch? It's optional rather than mandatory — a soft launch mainly reduces risk by surfacing issues at low traffic/spend before a bigger push, which is most valuable for a first-time or complex launch. A simpler store, or a founder who's confident in the technical setup, can reasonably skip straight to public launch.

How is this checklist different from the general ecommerce launch checklist elsewhere on this site? The general checklist is broader and includes business-formation and marketplace-oriented readiness (entity registration, bank account, marketplace-specific listing readiness) that applies regardless of channel. This one assumes that broader readiness is handled separately and focuses specifically on the technical and on-site work of getting a DTC storefront itself launch-ready.

What's the single most commonly skipped item on this list? Verifying tracking pixels actually fire correctly on the events that matter, as opposed to just installing them — a pixel that's technically present but misconfigured looks fine at a glance and often isn't caught until you're already well into spending ad budget against inaccurate data.