The episode airs at 10pm. By 10:02 there are more people on your store than visited in all of March, and by 10:45 most of them have gone. That shape, a vertical spike followed by a fast decay, is what a Shopify store ready for rapid growth has to survive. The part that breaks is almost never Shopify. It's the reviews widget loading from a vendor's shared server, the COD validation app that times out, the inventory count that was never going to cover 3,000 orders, and the free-shipping rule nobody tested above fifty orders an hour.
We've done the two-week sprint before a founder's episode drops more than once. Here's what actually matters, roughly in the order we work through it.
Work out the number before you build for it
Guessing "a lot of traffic" gets you nowhere. Put a figure on it and the engineering decisions make themselves.
A reasonable planning assumption for a national TV feature with a strong product moment: 45,000 sessions in the first three hours, with roughly 60% of those landing in the first half hour. That's 27,000 sessions across 1,800 seconds, so about 15 new sessions per second at peak. Shopify's infrastructure absorbs that without blinking. A third-party app serving a script from a single region does not always do the same.
Now the back end. At a 1.2% conversion rate, those 45,000 sessions produce roughly 540 orders on night one. Add the week of catch-up traffic and you might land near 3,000 orders in ten days. If your packing setup does 60 orders an hour and you run eight-hour days, 3,000 orders is more than six full days of packing with zero slack. Your SLA promise of "ships in 48 hours" is already broken on day two, and the support inbox tells you so.
Decide now whether you'd rather ship late or sell less. Both are defensible. Pretending neither will happen is not.
Cut the app scripts before you cut anything else
Spike traffic is overwhelmingly mobile, overwhelmingly first-time, and a lot of it is on patchy 4G in cities your Shopify Analytics has never highlighted before. A theme that loads in 2.4 seconds on your office Wi-Fi can take seven on a mid-range Android in Nagpur at 10pm when everyone else is also streaming.
The usual culprit is not the theme. It's the accumulated weight of apps installed over two years and never removed. We routinely find 600 to 900 KB of JavaScript injected by apps on a store doing modest volume: a reviews app, a wishlist, a currency switcher nobody uses, two analytics pixels that duplicate each other, a popup builder, and the remains of an upsell app that was uninstalled but left its script tag behind.
Audit every app against one question: did this earn revenue last month? If you can't answer, it didn't. Removing four apps and deferring the rest typically takes an LCP from around 2.4s to under 1.5s on mobile, and that single change does more for spike-night conversion than any amount of banner copy. Our write-up on Shopify speed optimisation covers the specific order we work in, and if you want the scan and the ongoing monitoring handled automatically, SwiftStore does the measurement and fixes a fair amount of it without a developer in the loop.
One more thing. Lazy-load everything below the fold, but never lazy-load the hero image. We get asked to "optimise all images" and then watch the LCP element get deferred into oblivion.
Inventory is the decision you cannot undo
Overselling is the single most expensive mistake on spike night, because the damage lands in public. A thousand people who paid and got a cancellation email three days later will say so on the same post that brought them to you.
Say you hold 900 units and the night produces 3,100 attempted orders. Your options:
- Let Shopify stop selling at 900 and show "sold out". Clean, honest, and you lose the other 2,200.
- Turn on pre-order for the overflow with a clearly stated dispatch date. Takes the cash, takes on the obligation.
- Take a partial prepayment on pre-orders, say ₹200 against a ₹1,499 product, and collect the balance on dispatch. Fewer cancellations than full prepay, less exposure than full COD.
Whichever you pick, set it up and test it a week before, not at 10:15pm. And if you sell across a warehouse and a retail counter, check how your inventory sync behaves under load. Most of the cheap sync tools poll on a schedule of a few minutes. On a normal Tuesday that's invisible. At 15 sessions a second it's a few hundred oversold units.
COD will eat the margin you think you made
New audiences from television skew heavily to cash on delivery, and their RTO rate is worse than your existing customers because the intent is thinner. Someone who saw a product for ninety seconds and tapped "order" is not the same buyer as someone who found you through search.
Work it through on 1,000 orders at ₹1,499:
- 620 COD, 380 prepaid.
- RTO on the COD orders at 24%: 149 parcels come back.
- Forward freight ₹80, reverse ₹80, packaging and handling ₹25. That's ₹185 per return.
- 149 × ₹185 = ₹27,565 of pure loss, before you account for the stock that comes back damaged or the working capital tied up for three weeks.
Two things cut that. First, a COD fee of ₹50 to ₹70 shown at checkout, which shifts a meaningful share of orders to prepaid without killing the sale. Second, an OTP confirmation or a partial COD prepayment on high-ticket items. We'd also hold COD off on your most expensive SKU entirely for the first week, and tell the customer why in one line.
On the payment side, Razorpay or PayU with UPI intent front and centre. UPI on mobile is the fastest path to a completed order in India and it should be the first option visible, not hidden behind "other payment methods".
Shopify Plus is probably not the answer yet
Founders ask us about upgrading in the fortnight before an episode airs, on the theory that a bigger plan handles bigger traffic. It doesn't work that way. Shopify's standard plans run on the same infrastructure, and your checkout isn't the bottleneck at 15 sessions a second.
What Plus actually buys you is checkout customisation through Shopify Functions, scripts for complex discount logic, Launchpad for scheduled sale events, multiple expansion stores and a higher API call allowance. Those become worth the monthly commitment when you're running frequent timed drops, operating across countries with different tax setups, or need discount logic the standard rules can't express. If you're doing under a few crore a year on a single catalogue, spend that money on inventory and performance marketing instead. We say this to prospects who arrive asking for a Plus build, and some of them do not enjoy hearing it. Our view on when the economics flip is on the Shopify Plus page.
The ten-day build list
Assuming you have a functioning store and roughly two weeks, this is the order we'd work in:
- Delete apps. Then clear orphaned script tags from the theme. This is a day of work and it has the largest effect of anything on the list.
- Build one landing page for the feature. Not your homepage. A page with the product, the price, the proof, and a buy button above the fold on a 390px screen. Homepages are built for browsers; this traffic has already decided.
- Test checkout on a real phone on mobile data. Every payment method, including COD, including a UPI collect request that you actually approve. Then test with a discount code applied.
- Set shipping rules and check the edge cases. Free shipping above ₹999 is fine until someone orders eight units to Port Blair.
- Fix the out-of-stock path. A sold-out product should offer email capture, not a 404 and not a bare "unavailable" button.
- Raise your Meta and Google spend caps. Retargeting the spike audience for the next fortnight is where the actual return sits, and a daily cap set in 2023 will throttle it.
- Set up the email and WhatsApp flows. Welcome, abandoned checkout, and a dispatch-delay notice you can trigger manually. Write the delay email before you need it, because you will write a worse one at 2am.
- Check GST invoicing. Correct HSN codes, place of supply, and B2B invoices with the buyer's GSTIN. Food brands, make sure the FSSAI licence number is on the packaging and the product page.
Anything not on that list can wait until the following month.
Day three is the real test
Traffic from a single broadcast decays by something like 80% within 48 hours. The founders who grow from it are the ones who treated night one as list-building rather than a revenue event.
So: capture email and phone on every exit, including from sold-out pages. Segment the spike cohort separately in your ESP, because their open rates and their unsubscribe rates will both be unusual and they'll distort your baselines for months. Send the first follow-up within 72 hours while recall is intact, not two weeks later when it isn't.
And watch your search terms in Shopify Analytics. A new audience looks for your product using words you never used. If 400 people searched a term your catalogue doesn't contain, that's a collection page and a product title waiting to be written. On larger catalogues, internal search quality is usually the cheapest conversion fix available after speed.
What this costs
A pre-launch hardening sprint of the kind described above, done properly on an existing store, is a two to three week engagement. A full rebuild on a modern theme with the same work baked in takes longer and costs more; the breakdown sits on our Shopify development cost page. The thing worth understanding is the ratio. The engineering spend is usually a fraction of what a single night of oversold inventory and RTO losses will take off you.
If your date is already set, the useful first step is a free audit of the current store: app weight, mobile LCP, checkout drop-off and the COD setup. We'll tell you which three things to fix and which ones don't matter. Takes about a week to turn around, and you can act on it with or without us.