You're Taxing Your Best Engineers to Save £300 on a Chip
The cheapest line on your capital budget is quietly the most expensive. Priced against salaries, a fast machine is almost always the bargain, and buying down is a tax on the people you pay most.
Here is a wager most firms would lose. Take the cheapest line on your capital-expenditure sheet, the desktop or laptop spec you standardise across the engineering floor, and bet it against the most expensive line, the salaries of the people using it. The hardware wins on optics every time and loses on economics almost every time.
The numbers are not subtle. Treat a senior engineer as costing, fully loaded, somewhere around £60 an hour: salary, employer's NI, pension, software, floor space. That figure is illustrative arithmetic, not a surveyed statistic, but it is the right order of magnitude for most UK teams. Now suppose a faster machine buys back twenty minutes a day of compile time, test runs and the small stalls that break concentration. Twenty minutes at £60 an hour is roughly £20 a day, close to £4,000 a year. The chip that recovers those minutes costs a few hundred pounds, once. You are declining a return a hedge fund would frame and hang on the wall.
So why does the downward-standardised spec survive? Because it is legible and the cost it creates is not. A cheaper machine is a number a procurement dashboard can display. Idle wait-time is smeared across a thousand invisible moments and never lands on a single report. The saving is booked; the tax is paid out of someone else's productivity. This is the oldest false economy in operations: optimise the measurable line, ignore the larger unmeasured one.
How fast is a fast CPU actually, compared with a slow one?
This is where honesty matters. On single lightweight tasks, a budget chip and a flagship feel identical. On the work that actually eats a developer's day, parallel compiles, container builds, local model inference, large test suites, the spread widens sharply, and on the most parallel workloads the gap between a current top-tier desktop part and a budget one a few tiers down can approach an order of magnitude. The exact multiple is workload-specific, and you should read independent benchmark suites for your own stack rather than trust any single headline number, including this one. What is not in dispute is the direction and the rough scale: after years of stagnation, CPU performance has genuinely diverged again, so the penalty for buying down is larger now than it was five years ago.
The timing is awkward. Memory and component prices are rising, which tempts finance teams to trim hardware spend at precisely the moment the productivity gap between fast and slow machines has widened. The supply side is turning political too. When a government converts subsidy into an equity stake in a strategic chipmaker, it acquires both a reason and the means to steer procurement toward that vendor. That is not a conspiracy, it is an incentive, and incentives are more reliable than conspiracies. Buyers should expect the 'strategic' option to be nudged in front of them more often, and price the quiet loss of neutral advice accordingly.
Is AI assistant 'memory' a feature or a switching cost?
The same capital-allocation lens explains a subtler trap. AI assistants now remember your context, your house style, the shape of your codebase. It is sold as convenience, and it is convenient. But read the incentive rather than the marketing. Every remembered preference is a small deposit of switching cost. The more the tool knows about you, the more it costs to leave, because leaving means re-teaching a competitor from zero. This is the data-gravity trap enterprises already recognise from every other platform they are locked into, re-imported through a friendlier interface. None of that requires anyone to have designed it as a trap; it only requires that the feature and the lock-in point the same direction, which they do. The defensive move is to treat accumulated personalisation as an asset you own and can export, not one the vendor holds. We have argued before for keeping practical AI under human control rather than ceding it by default.
The thread joining these is a single reframing: stop treating compute and tooling as commodity line items, and start treating them as capital allocated against the cost of the people who use them. A CPU, a licence, an assistant's memory, each is cheap measured in pounds and expensive measured in dependency or foregone time. The discipline is to price every technical decision in the currency that dominates the equation, which is almost always salaries. That is the logic behind how we approach technical strategy, and why we push clients to settle readiness before they build.
What would change my mind on the hardware point? Two things. If a team's work were genuinely light, browsers, documents, email, then the fast machine buys nothing and the cheap spec is correct; not every desk needs a workstation. And if the time saved simply refilled with waiting elsewhere, a slow network, a shared build server, a meeting culture, then the CPU was never the binding constraint and upgrading it is theatre. Fix the actual bottleneck, not the one that is easiest to purchase. The claim is not 'always buy the fastest thing'. It is 'find the constraint on your most expensive people, then notice how often it costs three figures to remove and how rarely anyone removes it'.
The asymmetry is the whole story. Buy the wrong cheap chip and you lose thousands in slow, deniable increments. Buy the right expensive one and the downside is a few hundred pounds you would have spent within the year anyway. When the loss is capped and small and the gain is large and compounding, the rational bet is obvious. Most budgets make the other one.
Questions people ask
How do I justify faster developer hardware to finance?
Reframe it as capital allocated against salary, not a hardware line item. Estimate the loaded hourly cost of the person, estimate the minutes a day lost to slow builds or waiting, and multiply out to an annual figure. Set that against the one-off price of the upgrade and quote the break-even in days, not the sticker price.
Does a top-tier CPU really make a measurable difference to knowledge work?
It depends entirely on the workload. For light tasks the difference is negligible, so the cheap spec is right. For parallel compiles, container builds, local model inference and heavy test suites the gap can be large. Check independent benchmarks for your own stack before committing, because the multiple varies enormously by task.
Why is AI assistant memory described as a switching cost?
Because every preference the tool remembers is context a competitor would have to relearn from scratch. That raises the cost of leaving, which is the definition of a switching cost. It is analysis of the incentive, not an accusation of intent: the convenience and the lock-in simply point the same way. The mitigation is to keep your personalisation exportable.
Related
- Epic v Google: The App Catalogue Remedy That Hands Rivals the Moat
- Memory Prices Turned. Renegotiate the Supply Contract Before the Next Refresh.
- How AI Makes Bad Bosses Worse: The Agreeability Machine in the Corner Office
- Digital Business
Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.