Sixty devices, fewer than thirty-five actually running
A reader running a studio did this arithmetic for me last year.
He bought sixty iPhones in one order. Fewer than thirty-five ever ran. The remaining twenty-odd sat on the rack for seven months, during which he dutifully charged them, updated the OS and cleared the dust.
He said the money was not the worst part. The worst part was exiting: twenty-odd identical units at once, few buyers, and him the motivated seller, so the other side set the price. It closed at roughly sixty per cent of what he paid.
“Buying was one action. Selling was one thing after another.” His words.
This article only does that arithmetic. Three others here deal with Apple cluster control devices from a technical and selection angle:
- One on the six common technical pitfalls of a device matrix — identification, cabling, naming, parameters, records, versions
- One on choosing devices before buying — models, batteries, locked units, matching models, how many to buy first
- One on capacity bottlenecks and hardware configuration
None of them covers what happens after you buy too much. This one does — the costs of losing control of scale. No technical solutions, just money, time and room to manoeuvre.
Cost one: idle hardware does not get cheaper on its own
“Buy it now and keep it spare, we will need it eventually” — that thought is unusually expensive when it comes to devices.
Because idle does not mean paused. A device powered and waiting, or even unpowered but already past its factory date, is doing four things at once:
- The battery is degrading naturally — lithium ageing depends on time and storage charge, not only cycle count
- The OS is falling behind, narrowing the window in which your scripts stay compatible
- The warranty is running out
- Resale value is dropping — time value on consumer electronics only moves one way
Decide to deploy it six months later and you do not receive “a new device”. You receive one that needs battery attention, needs an OS upgrade, and has already passed its value peak.
The cost of idle stock does not show up at purchase. It is still accruing.
Cost two: maintenance cost is not linear
The most under-estimated of the five, because it is not “more of the same work” — the nature of the work changes.
Under ten devices, a fault is an individual event: something fails, you fix it, you move on. It costs a bit of time and a hand.
Past thirty, faults start arriving in clusters. What you now need is not faster repair but a mechanism — records, attribution, rotation. Which devices came from the same purchase batch, which were repaired recently, which faults keep recurring. The mechanism has to be built, maintained and staffed.
So tripling the fleet can quintuple the operational load. That non-linear portion is usually absent from the budget, because it presents as “someone’s time got eaten” rather than “an extra expense”.
Cost three: account supply falls behind
The most frequently mismatched link in Apple cluster control scaling.
Devices are easy to buy; accounts are not easy to raise. Buying thirty machines is a one-off: contract, payment, delivery, done inside a week. Thirty usable accounts take time — registration, verification, warming, gradual trust. Each has its own cycle, and the cycle cannot be compressed. Compress it and you trade account quality, paying more later.
The result is a schedule mismatch: devices arrive, accounts are not ready, and the surplus sits empty while depreciating.
So pace expansion by account maturity, not by delivery date. Before buying devices, ask: how many accounts can go live immediately?
Cost four: taking the wrong jobs to fill capacity
The least visible of the five, because it does not present as an expense. It presents as a series of decisions bending out of shape.
Idle hardware creates pressure. Looking at a row of empty machines, the instinct is “I need to get these running”. That pressure pushes toward decisions you would otherwise not make: low-margin jobs, higher-risk business, clients with vague delivery terms.
One test works well: if you would have declined the job with five devices, it is probably not worth taking to fill thirty.
Devices are a tool, not a goal. Taking work in order to use the tool lets the tool decide your business direction.
Cost five: exiting is harder than entering
Entering is a clean expense: budget, order, delivery, rack. Exiting is friction.
- Bulk discounts are steeper. A single unit on the second-hand market has many buyers and little price pressure. Thirty at once means few buyers, and you are the motivated seller — so the other side sets the price.
- Devices that ran a business need data handling. Account bindings, login records, local residue. Both time and risk.
- Mixed models are harder to move. If you accumulated them in batches, the models buyers want will not match your stock.
- The time cost. Listing, negotiating, testing, shipping. Exiting thirty devices often takes more effort than buying them did.
So the problem with over-buying is not that you chose wrong. It is that you put yourself in a position you cannot exit when you want to.
A steadier scaling pace
One principle: scale to demand, not to price.
A low price is not a reason to expand. Prices fall constantly — cheap this year, possibly cheaper next — while your devices depreciate from the moment they arrive. Buying early to “catch the price” usually saves less than the idle period costs.
Concretely:
- Confirm a concrete queue of tasks is waiting — concrete, not “the business will grow”
- Buy only what that queue needs, with no “we will need it eventually” padding
- Once steady, keep an observation window and confirm online rate, success rate and resolution time are normal
- Then the next tranche, still sized by demand
A second benefit of tranching is attribution. Add one tranche at a time and you can tell whether a new problem belongs to the new hardware or somewhere else.
How many per tranche? Size it to complete the current queue, with no more than twenty per cent margin. That margin covers arrival faults and temporary replacements, not new business. Anything beyond it is a bet on growth.
One cost item that gets missed: the accessories. Thirty devices means not only thirty iPhones but hubs, independent power, cables, mounts and spares. Together these usually add in the low teens as a percentage of the device spend. Budget only the handsets and the second purchase goes over.
If you have already over-bought
Three moves, not mutually exclusive:
First, put idle devices on low-risk tasks. Producing some value beats sitting and depreciating. Hold one line here: low-risk only. Do not take on extra risk just to give hardware something to do.
Second, if they genuinely will not be needed soon and the models are not yet obsolete, sell sooner rather than later. Value declines with time; waiting is not a strategy.
Third, stop buying and redirect the budget to the real bottleneck. In most cases a team that over-bought devices is actually short of accounts and content. Money spent there beats another twenty machines.
Back to those sixty devices. He sold them in three tranches over four months — longer than the original purchase took.
The one thing not to do: buy low-quality traffic or accounts to use the hardware up. That converts the cost of idle devices into a larger business risk.
Finally
The right order is: demand confirmed → accounts ready → devices purchased → observation window → reassess. Devices come third, not first.
Three related articles, best read in this order: is a used iPhone any good for cluster control, then one console running 100 iPhones, then why a device matrix keeps going wrong.
About EasyClick: A phone automation AI-agent platform covering Android no-root, iOS no-jailbreak (proxy / Bluetooth HID / OTG HID) and HarmonyOS Next, offering script development, Apple cluster control, local central control & mirroring, and cloud control systems. → Explore all products
Ready to build it for real?
Every approach in this article can be built with EasyClick capabilities on iEasyClick — full documentation, developer tools and automation products, free to try.