This series started with a 2015 MacBook that seemed to have reached the end of its useful life. It ended with a concrete diagnosis (disk I/O, not software), a fix applied without spending a cent on new hardware, and a question that comes up constantly, both in my own decisions and in my clients': when do you optimize, and when do you simply buy new equipment?

The short answer is that it depends on objective data, not on the frustration of the moment — which is precisely the state of mind most people are in when they make this decision.

The framework: four objective signals that mean "buy now"

Based on the diagnosis I documented in this series, these are the signals that the problem is no longer configuration but the hardware's physical limit:

  • A load average above 8–10 at complete rest, sustained — with no heavy apps open, the system keeps showing high load consistently, not occasionally
  • Kernel panics or unexpected shutdowns — not just slowness. An abrupt system crash signals a more serious problem than a simple resource bottleneck
  • Build times that keep climbing consistently — not an isolated spike one day, but a sustained trend where compiling or running tasks takes longer and longer
  • Constant swap visible in Activity Monitor — the system using disk as RAM in a sustained, not occasional, way is a clear sign that physical RAM no longer covers your current use

The rule of thumb I apply: two or more of these signals sustained for at least a week justify bringing the purchase forward. A single signal, or symptoms that come and go, almost always point to something diagnosable — as I found with my own Mac.

"The cost of work time lost to a bad diagnosis often exceeds the cost of new equipment. But buying without diagnosing first is betting that the problem was hardware — and sometimes it isn't."

Why the diagnosis is what changes the decision

In my case, the high load average wasn't a sign of the hardware's physical limit — it was disk I/O caused by a specific usage pattern, solvable without buying anything. Had I reacted to the first symptom (general slowness) without diagnosing, I would probably have spent money on a new machine to "solve" a problem that actually had a concrete, fixable cause.

That doesn't mean you should never buy new equipment — it means the decision should rest on the framework's objective signals, not on the accumulated frustration of a hard week. My goal of upgrading to an M-series MacBook by the end of 2026 still stands, but with this diagnosis I gain real working time in the meantime, without sacrificing productivity or making a rushed purchase.

The transferable lesson from the whole series

The message that connects the articles in this series — see the real cause of a slow 2015 MacBook, the Terminal commands to diagnose it, Chrome vs Safari on an old Mac and installing Node.js and Claude Code without permission errors — and that I apply equally to client projects is the same: diagnose before you react. Whether in code, in hardware or in a digital business, the temptation to "fix" the first visible symptom without verifying the root cause costs more time and money than the diagnosis itself.

Frequently asked questions

When is it worth optimizing a computer instead of buying a new one?

When the diagnosis shows a concrete, solvable cause — such as software-driven disk I/O, lack of maintenance or configuration — and there are no signs of sustained physical failure. Many "slow computer" cases can be diagnosed and solved without buying new hardware.

What signals indicate it's time to buy a new computer?

Four objective signals: a load average sustained above 8–10 at complete rest, kernel panics or unexpected shutdowns (not just slowness), build times that climb consistently, and constant swap usage visible in Activity Monitor. Two or more signals sustained for a week justify bringing the purchase forward.

Why does diagnosing before deciding save money and time?

Because buying new equipment without diagnosing the real cause of the slowness may solve the symptom without guaranteeing the problem won't return if the cause was configuration or maintenance. Diagnosis turns a decision based on frustration into one based on data.