Store launch
A working store, live, with the boring parts done properly.
A complete launch: theme, catalogue, payments, shipping, taxes, policies, tracking and the pre-launch checks. The scope is fixed in writing first, so the price does not move mid-build.
Fixed price
From $4,250
That covers a launch on a preset theme with up to a hundred products, one country and standard payments. Several markets, supplier feeds or a migration push it towards $14,500. The number is fixed in writing before anything is built.
Send the brief and get a number back.
Describe the projectThe launch date moves because of the parts nobody scoped
The theme is the visible half and it finishes roughly on time. Then payments need identity documents from a director who is travelling, tax settings need decisions nobody has made, shipping zones need real rates instead of a flat guess, the legal pages need an address you are willing to publish, four hundred products arrive with no barcodes and three photos between them, and the order confirmation lands in spam because nothing was ever set up in DNS. The launch slips by a month, and the reason is never the part that was quoted.
What a launch includes
Scope written down before anything is built
A list of everything that has to exist before the store can take an order, priced up front, with each line marked as ours or yours. That document is what stops the price moving in week three, and it is also the fastest way to find out that the launch depends on something only you can do, like a bank account or a supplier's product data.
The unglamorous half done properly
Payments and their verification, tax configuration, shipping zones with rates that reflect what carriers charge, order and shipping notifications, DNS with SPF and DKIM so email arrives, consent and analytics wired before traffic rather than after, policy pages, and a catalogue import that does not need redoing.
Acceptance as a buyer, not as an administrator
Real orders placed through each payment method, from each country you sell to, on a phone and on a desktop, followed all the way through to the confirmation email, the notification to you, and a refund put back. An admin that looks correct and a checkout that works are different claims.
Why it is done this way
A price only holds if the scope was written
Launches go over budget because the quote covered the design and the build, and the rest arrived as discoveries. Writing the whole list first is uncomfortable, because it makes the real cost visible early, and that is the point. You can cut the list before it is built. You cannot cut it after it has become the reason you are not live.
Selling into the European Union carries rules older than your store
The General Product Safety Regulation has applied since December 2024 and expects a named manufacturer, an EU responsible person, warnings and traceability. The European Accessibility Act has applied since June 2025. Consumer law expects a withdrawal right, prices including VAT and a reachable business identity. These are configuration and content decisions that belong in the launch rather than in a panic afterwards. This is information about what stores are asked for, not legal advice, and no compliance outcome is warranted here.
How it runs
A scoping pass: what you sell, where to, how it ships, who handles support, and what already exists. It ends in a written list with a price and a division of labour.
You start the slow things immediately: payment provider verification, the bank details, the domain, and whatever product data has to come from suppliers. These wait for people, not for code.
The build, in the order that lets you start loading products early rather than at the end, on a store nobody can reach yet.
Pre-launch checks against a written list: test orders per method and per country, tax and shipping on real addresses, emails arriving, tracking firing once, policies present, mobile checked.
Launch, then two weeks of watching real orders rather than declaring victory, because the first genuine customer always finds something the tests did not.
Background
What actually decides when a store goes live
The critical path runs through people, not code
In most launches the build is not the constraint. Payment providers verify identity on their own schedule and will ask for documents twice. Suppliers send product data in whatever shape they have. Banks take a week. A director on holiday can hold a launch longer than a rewrite. This is why the scoping pass hands you the slow items on day one instead of surfacing them in week four: they are the only things a developer cannot go faster on, and they are almost always what moves the date.
The European checklist that is not optional
A store selling to consumers in the European Union is expected to carry things that have nothing to do with design. The General Product Safety Regulation, applying since December 2024, expects a named manufacturer, an EU responsible person for imported goods, warnings and traceability information. The European Accessibility Act has applied since June 2025. Consumer law expects a withdrawal right, VAT-inclusive prices and a business identity a buyer can actually reach. These are decisions with content attached, which is why they belong in the launch scope. The description here is informational and not legal advice, and no compliance outcome is warranted.
Test orders are the acceptance, not the demo
Almost every launch failure in the first week is something that looked right in the admin: a payment method that works for the owner's card and not for a foreign one, a shipping rate that returns nothing for an address in another region, a confirmation email that goes to spam, an analytics event counted twice, a tax line that appears only above a certain amount. None of these show up in a walkthrough. They show up in an order placed the way a stranger would place it, which is why the checklist is written and worked through rather than performed.
The first two weeks are part of the job
A launch is not finished when the store is reachable. Real customers use paths the tests did not, on devices nobody had, with addresses that break a validation rule. The fortnight after go-live is when those surface, and it is worth treating as scheduled work rather than as goodwill. Nine launches in the portfolio ran this way, across twelve live domains, into Poland, Ukraine, Mexico, Brazil, the United States and worldwide.
Describe the project
Tell us what you have and what should change. Within two working days you get a written calculation: the scope broken into parts with a price against each, or the questions needed to write one. No discovery call in between.
Questions
Launching a store, asked and answered
A straightforward catalogue on a current platform is usually weeks. What extends it is rarely the build: payment verification, product data that does not exist yet, a supplier feed, several countries, or a migration with order history. The scoping pass exists to tell you which of those you are in before you commit to a date, especially if the date is a season.
Decisions and access, mostly. The company details that go on invoices and policy pages, the payment provider account with its verification done, product data in any structured form, images, shipping rates you can honour, and one person who can answer questions the same week. That last one moves launch dates more than anything technical.
Yes, and it is often the better plan. A store with sixty products that are properly described, photographed and in stock sells better than one with six hundred half-finished ones, and it lets you learn what buyers ask before you have written four hundred descriptions the wrong way. The import stays repeatable so the rest can arrive in batches.
It overlaps but it is bigger. A migration adds URL mapping and redirects so you do not lose search visibility, customer and order history where the platforms allow it, and a cutover plan with a rollback. That is scoped separately because pretending it is a launch is how sites lose their rankings on go-live day.
Everything: the store, the accounts in your name, the theme source, the written list of what was configured and where. Nothing is held on our accounts and nothing requires us to be reachable for the store to keep running. If you continue with maintenance afterwards, that is a decision made on the work rather than on a lock.