A 40-SKU drop should be an afternoon of Shopify work, not a fortnight. When it does take a fortnight, the delay is almost never in the platform: it's the photographer's turnaround, a copy doc nobody has signed off, and a product page that gets rebuilt from scratch every single time because nobody ever made a template. Shopify helps D2C brands launch new products faster by killing that third one, and it only does it if you set the store up deliberately. Out of the box, Shopify will happily let you hand-build every PDP forever.
Where the two weeks actually go
Before touching anything technical, time your last launch honestly. In the launches we've worked on, the split usually looks like this: five to seven days waiting on retouched images, two days on copy and legal-ish claims, one to three days building pages, half a day of QA, and then a scramble on the morning of the drop because someone spotted a wrong variant price.
Shopify can compress the build, the QA and the publish. It cannot photograph your product. If your bottleneck is a studio that takes nine days, a Liquid refactor buys you nothing. Fix the biggest queue first, and be willing to hear that it isn't the website.
Build the product page once, then stop building product pages
Online Store 2.0 gave every product its own JSON template. The point of that, for a brand that drops regularly, is that you create one launch template with every block the category needs, and every new SKU inherits it at creation.
A skincare template might carry: hero gallery, a claims strip, a full ingredient list, a how-to-use block, an FSSAI-relevant label panel with net weight and shelf life, a shade or size selector, and an FAQ. None of that should be typed into a rich-text description field. Put each piece in a metafield with a defined type, and have the section render it. Empty metafield, block hides itself.
Metaobjects handle the shared content. Your size chart, your wash-care legend, your returns policy for perishables: define once, reference from as many products as you like, edit in one place when the policy changes. We've seen stores with the same size chart pasted as an image into 300 product descriptions. Changing a single measurement then becomes a week of work.
The awkward case: if your categories genuinely differ, you need more than one template, and people forget to switch. Name them clearly (product.apparel, product.food, product.gifting) and make template assignment part of the import file rather than a manual dropdown.
The arithmetic on a 40-SKU drop
Here's the calculation we run with founders who think this is over-engineering.
Hand-building a product on a store with no template and no metafield definitions: create the product, upload and reorder six images, paste and format description HTML, build the size chart, add variants and prices, write SEO title and description, assign collections, set tags. Call it 18 minutes if the copy is ready and nothing goes wrong. Across 40 SKUs that's 720 minutes, or 12 hours. One person, a day and a half, and by SKU 30 the formatting has drifted.
With metafield definitions in place, a CSV built from the same sheet the copywriter works in, and a template assigned on import: the import runs in a few minutes, and a human spends about 4 minutes per SKU checking images and pricing. That's 160 minutes, under three hours.
Setup cost for the definitions, the template and the import mapping: roughly 6 to 10 hours the first time, more if you want custom sections built. So the first drop roughly breaks even. The second drop saves you nine hours. The fourth has paid for a developer's week. If you launch twice a year, honestly, don't bother. If you launch monthly, you're burning money by not doing it.
Automate the tagging so merchandising isn't a manual step
Tag every product in the drop with something specific at import: drop-2026-01, not "new". Then an automated collection with the rule tag equals drop-2026-01 builds your landing page before you've finished your coffee. A second automated collection on tag equals new-arrivals keeps the sitewide nav honest.
Shopify Flow handles the rest for stores on Plus: when a product is created with a given tag, publish it to the channels you want, add it to a manual collection, notify the merchandising channel in Slack. On the basic plans you can get most of the way with automated collection rules and a disciplined tagging convention. The convention matters more than the tooling.
Two things that break here. Automated collections sort by "best selling" by default in some themes, which means a brand-new SKU with zero sales sinks to the bottom of the page you built for it. And if your collection has hundreds of products, a shopper who came for the new lipstick shade has to scroll past everything else. That's a filtering problem, not a launch problem, but it shows up on launch day.
Scheduled publishing, preview links and the 48 hours before go-live
Keep the products in draft, build the collection, then use the publish date per sales channel so the drop goes live at 11am without anyone sitting at a laptop. For sign-off, share a theme preview link rather than pasting screenshots into WhatsApp. Founders approve faster on their phone, and you catch the mobile layout bug at the same time.
Pre-orders are worth the setup if your manufacturing lead time is long. Shopify's selling plans, or a pre-order app, let you take payment ahead of stock and continue selling past zero inventory. One blunt piece of advice for India: don't offer COD on pre-orders. You are asking a customer to remember, three weeks later, a decision they made on impulse, and the RTO rate on that is ugly. Prepaid only, with a clear dispatch date on the PDP and in the confirmation email.
If you're not ready for pre-orders, a "notify me" capture on the out-of-stock variant is the cheapest launch asset you own. That list converts better than any cold audience you'll buy on launch week.
Where Indian launches break
The platform work is the easy half. What actually delays go-live for brands selling in India:
- GST and HSN per SKU. Your invoicing app needs an HSN code and a tax rate for every new product. Apparel in particular sits in different slabs either side of a price threshold, so a last-minute MRP change can quietly change the tax you're charging. Put HSN in a metafield and populate it in the same import.
- Multi-location inventory. This is where we get it wrong on the first pass maybe a third of the time. New products import with stock assigned to the wrong location, or to no location, and the storefront shows sold out on launch morning. Check the inventory-by-location view before you publish, not after.
- Razorpay and COD rules. If you gate COD by pincode, order value or product type, new SKUs need adding to whatever list drives that logic. A ₹4,000 launch item slipping into the COD-eligible bucket by default is an expensive oversight.
- FSSAI and label data for food. Net quantity, ingredient list, best-before convention, licence number. It belongs in structured fields, because you will be asked for it and you do not want to be searching 60 descriptions.
Launch day is a speed problem
Traffic spikes on the one day your pages are heaviest: fresh hero images straight from the retoucher, a countdown timer app, a popup, sometimes a video. We've opened launch pages with a 3.8MB hero JPEG sitting above the fold and an LCP over 4 seconds on a mid-range Android on 4G. That is the device most of your Instagram traffic is using.
Practical fixes, in order of payoff: export heroes at the width the section actually renders and let Shopify serve WebP, preload the LCP image, lazy-load everything below the fold, and audit the app scripts loading on the collection and product templates. Every abandoned-cart app you trialled in 2023 and never uninstalled is still costing you render time. Getting a 2.4s LCP under 1.5s is usually a day of work, not a replatform.
If you want a running check rather than a one-off, our team publishes SwiftStore on the Shopify App Store, which scans the store's PageSpeed, fixes what it can automatically and tracks the score over time so you notice the regression the week it happens. For the deeper theme-level work, our speed optimisation service covers what an app can't touch.
When your launch cadence justifies Shopify Plus
Plus earns its keep for launches when you're doing scheduled, high-traffic drops with tiered pricing logic: early access for a segment, automatic gift-with-purchase above a cart value, a discount stack that regular Shopify discounts can't express. Shopify Functions and scripted checkout customisations are the real reason to upgrade, along with the checkout branding controls.
If you drop four times a year and your promotions are a flat percentage off a collection, Plus will not make your launches faster. The upgrade cost is better spent on photography and paid media. We say this to brands regularly and it's occasionally unwelcome. When the maths does tip, our Shopify Plus team handles the migration and the Functions work.
The checklist we run before a drop goes live
- Every SKU has the right template, and a spot check on three of them renders every metafield block.
- Inventory sits at the correct location and the storefront shows it available.
- Prices, compare-at prices and tax settings match the sheet finance signed off.
- The drop collection is sorted manually, or by a rule that doesn't bury new products.
- COD eligibility and shipping rates behave for the new price points. Test with a real pincode from a tier-2 city, not just your office address.
- Product images pass a mobile PageSpeed run on the collection page.
- Publish dates set per channel, including Instagram and Google if you sell there.
- One person owns the go-live hour and has admin access on their phone.
Take your last launch and write down how long each step took. If the Shopify build was more than a day of it, the template work will pay for itself within two drops, and you can scope it with a free store audit before committing to anything.