The Move to the Mini

For six months the brain of my whole operation lived on a laptop. That sentence should have worried me more than it did.

The laptop was a MacBook Pro on a desk in Florida. It ran the command center I use for my day job in planned giving, the scheduler that drafts my donor emails every morning, the local AI models, the search index, the bots that text me, and the tunnel that puts all of it on the web. It was fast and it was quiet. It was also a laptop, which means it was built to be closed, carried, updated and put to sleep.

On a Wednesday in October it did exactly what laptops do. It installed an update overnight and restarted. When it came back up, its network connection was off. I was a thousand miles away in Indianapolis. Nothing could reach it, and it could not reach anything. Eleven donor drafts that should have been waiting for me that morning sat on a machine nobody could talk to.

The machine was fine. The setup was the problem. Nothing had crashed. No data was lost. A computer behaved like the kind of computer it was, and I had been asking it to be a different kind.

I made two decisions that morning. The first was easy. I paused all donor outreach until the next Monday. My partner on this, my AI chief of staff, reset the whole week so nobody got a duplicate email or a call out of nowhere. A quiet week beats a sloppy one.

The second decision was the real one. I had a Mac mini in the same office, bought over the summer and never fully put to work. A mini has no lid and no battery. It does not travel. It is built to sit in one place and stay on. Everything would move to it, in one day, that Saturday.

We wrote the plan before I got home: a checklist of every job, every scheduled task, every file the system writes and every service it listens for. When I walked into the office Saturday morning, the laptop came back the moment I plugged in a network cable. The whole outage had been one setting. We used it as the source and started moving.

By about five that evening the mini was running everything. The command center. The schedulers. The models. The search index. The tunnel that serves seventeen web addresses moved in a single step, because all seventeen point at whichever machine runs it. I turned on automatic login so a power blip cannot strand it at a password screen, and I turned off sleep. It has one job now, and the job is to be there.

Monday was the first clean day on the new machine. Ten emails, five calls and five texts, all drafted and waiting before I sat down.

Then came the part nobody puts in the migration plan: the week after. A move like this does not fail on cutover day. It leaks for a week. A scheduled evening report kept running in the cloud instead of on a computer, and failed every night without a sound. A small app I use for clinical paperwork looked dead, but it had only moved to a new address and my phone was still calling the old one. Two jobs that sync my investment accounts stopped, because the new operating system blocks the built in Python for background work. My home page took twenty five seconds to load, because it was waiting on an email scan the move had made pointless.

None of those were broken in the way broken usually means. Each one was pointing at the wrong place, or waiting on something it no longer needed. We found them by testing every page and every data feed on the new machine, one at a time, and writing down what came back. The home page loads in a hundredth of a second now.

The line I keep coming back to is one my partner wrote in August, two months before any of this: separate duty from desk. Production belongs on a machine nobody types on. The laptop is mine again. It travels with me, it sleeps when I close it, and nothing important depends on it being awake.

If your business runs on a computer you also carry around, you do not have a server. You have a very fast single point of failure with a lid. Move the work to something that never leaves the room. Then plan for the week after, because that is where the real work is.

MG