Every Shop Has a Part That Gives Way First. Most Find Out Which on the Day.

The sale opens at midnight. The email went to every customer at eleven.

By ten past twelve the website is crawling. The technology head is on a call with three engineers, restarting one thing after another to see what helps.

At two in the morning they find it: every page was waiting on one stock table that could answer one question at a time. By then the first rush has gone elsewhere.

What We Found

For this article we went through the public record on old software that met more than it was built for: reporting on a long-serving system that could not keep up, a capacity figure for a national booking system given in a parliamentary answer, and two surveys on how firms see their old technology, from 2025 and 2026.

First, what we did not find. The retail research behind this article holds no evidence at all on shops slowing or failing at peak times: no named retailer, no figure for sales lost. Every fact below is from outside retail, and labelled so.

Software can work for years and still have a limit nobody has seen. This is an airline, not a shop, and a storm, not a sale. At a large US airline, crew-scheduling software about two decades old could not keep up with the changes after a winter storm in 2022, and thousands of flights were cancelled. The airline recorded losses of over one billion US dollars, and the US transport department fined it. Nothing on an ordinary day had shown where its limit was.

Every system has a ceiling, even when it is very high. This is a railway, and we pass no judgement on it. In a written answer in the Lok Sabha in August 2025, the railway minister said that “the booking capacity of the current PRS”, the passenger reservation system of Indian Railways, a government body, “is about 25,000 tickets per minute”. We report the figure as given, and use it for one point only: a ceiling can be stated. In most old shops, nobody can state theirs.

Firms feel that their technology holds them back. In one vendor-sponsored survey of a few hundred leaders at mid-size US and UK manufacturers, retailers and wholesalers, more than nine in ten said their existing technology limits their ability to succeed in online selling, and about seven in ten agreed that outdated technology is holding them back. The sponsor sells commerce software, and the research behind this article judged the first figure likely to be overstated. The survey is not about peak days.

“It still works” is the commonest reason to leave old systems alone. In one cross-sector survey of about five hundred IT professionals in the US, half said the biggest reason they had not upgraded was that the current system still works. On an ordinary day an old shop does still work, which is why its weakest part stays hidden.

Our reading: a shop built for an ordinary day has one part that gives way first under a rush, often the stock check, the payment step or the shared database. Nobody knows which, so the business finds out on the one day it can least afford to.

What Waits on a Limit Nobody Knows

A slow peak is usually called bad luck on the day. Our reading is that the cost was set months earlier, by not knowing.

The first cost is planning blind: marketing asks what the shop can take, nobody can say, and the campaign is held back or sent into the unknown.

The second is the wrong fix: servers are what can be bought quickly, so servers are bought. Whether they were the limit, nobody checked.

The third is the lost lesson: what was found at two in the morning lives in one engineer’s memory, and the next peak finds the same part.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Prepare for the Next Peak, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Add servers or a bigger hosting plan	The limit really is a shortage of capacity, and the shop’s parts can share the work	It does nothing for a part that serves customers one at a time, and the bill rises each year
Move the hosting to the cloud	The shop’s parts can run as many copies, and the firm is free to use the cloud	A hosting move is a project with its own risk, and a busy day in the cloud costs more than a quiet one
Replace the whole shop	The shop is beyond saving and the firm can carry a long project	Nobody knows which limit the old shop had, so the new one may carry the same design
Read the code to find the part whose design is the limit, then rebuild that part	Slow peaks keep coming back, even after servers were added	It costs money before anything is faster, and removing one limit shows the next

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own shop, each with a target. For this issue it would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Shared parts of the shop (database, stock check, payment step)	Not listed	Each one listed, with the pages and jobs that wait on it	The specification
How each shared part is built	Assumed fine, because the ordinary day is fine	Marked: built to serve many at once, or one after another, as read from the code	The risk register
The part most likely to give way first	Found on the day, if at all	Named before the peak, with the reason	The risk register
What each limit would need	”More servers”	Matched to more capacity, a change to the code or a rebuild	The cost comparison and the staged plan
Behaviour at peak volume	Learned from customers on the day	Measured before the peak in a load test your team arranges; we claim no figure	Your own load test, outside our work

The starting points above are what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a retailer.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the shop and the last peak. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the code your shop runs on that your firm built or had built. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the part whose design is the limit, rebuilt beside the old shop. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

What we do not do: we do not monitor or run your shop, we do not host it, and we are not on call on the day of a sale. We promise no uptime, no speed and no capacity. Our assessment does not include a load test, and we do not run load tests; only a test gives a number. A packaged or hosted shop platform’s capacity is its supplier’s matter: we do not install, upgrade, move or choose shop platforms. We do not secure or scan a shop, and we have no published case of this work for a retailer.

What changes for the business:

Role	What they gain
CEO	The biggest trading day stops being a day to dread, because the weak point is known and there is a plan for it.
CTO or CIO	A list of the parts that cannot grow with demand, in order, in place of a guess made at midnight during the sale.
CFO	Money for capacity goes to the part that limits sales, and not to everything at once.
COO	Operations knows beforehand what a slow shop would do to orders and dispatch, and has decided what to do.
Head of marketing	Marketing knows which part of the shop a big send would strain first, and books the campaign with that in view.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
A large US airline’s crew-scheduling software, about two decades old, could not keep up after a storm in 2022, and thousands of flights were cancelled.	Our part is far narrower, and in another industry; we do not say what would have helped. For an application a retailer built, we read how it is made and show which parts cannot serve many users at once.
Indian Railways’ passenger reservation system: about 25,000 tickets per minute, as the railway minister told the Lok Sabha in August 2025.	We make no comment on the railway and do not work on systems of that kind. For a retailer’s own application, we read the code to show where its limits are likely to be set; we do not measure the figure.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We find the part that gives way first in a quiet month, so nobody has to find it at midnight.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →