Building the Machine, Days 14 to 17: The Laptop That Belonged To Disney

What actually happens when the machine underneath your AI stack can’t hold the weight anymore.

Four days gone. Not because the work was hard. Because I never checked what my machine was actually running until it stopped running at all.

Day 14, July 28. I got real building done that day, nothing worth writing home about on its own. But it was day one of my MacBook Air starting to choke mid-task. Apps freezing, spinning wheel, work grinding to a stop. I pulled up Activity Monitor to see what was going on and found memory pressure pegged in the red. Roughly 22GB of memory in use, on a machine with 16GB of physical RAM installed. That’s not a typo. That’s macOS compressing and swapping to disk to fake room that isn’t there, which is exactly why everything felt like wading through mud. It never occurred to me I’d outgrow 16GB. I just wasn’t thinking about it until the machine made me.

Here’s what’s actually running to get there. Littlebird, open all day every day, because it’s the tool I run 90% of my actual working hours through, and if you want to see why, click the link. Claude, open the whole time doing the real thinking and building work with me. Cursor, my only IDE and my only terminal; everything SSH- and CLI-related runs through it. On top of that, tab groups. Not forty random tabs I’m scared to close, actual organized groups. One called “AI development” holds the database dashboard, the hosting panel, the domain registrar, the mail client, the DocuSeal account, the Stripe dashboard. Stuff you’re back in constantly even when you’ve got AI agents doing the heavy lifting. Convenient as hell. Also taxes RAM the whole time it sits open.

Day 15, July 29. I fumble-fucked around with settings for about an hour, got nowhere, gave up, and started shopping for a used Mac because new ones aren’t cheap. Meanwhile I still had actual work to do. I sat down to spec out a piece of the Deploy Day launch. Send a prompt. App crashes. Reopen it. Dig back through whatever I’d already gotten before it died. Pick the workflow back up wherever it broke. That was the whole day. Not one clean hour of forward motion, just that loop on repeat.

Day 16, July 30. Backed everything up, reset the Mac Mini, drove out to a shop that had a used M1 Max, 32-core GPU, solid spec. Trade math worked to swap the Mini and the Air for it straight across. Got it home, powered it on, and it booted into a Remote Management screen. MDM enrollment required. Registered to Disney Worldwide Services, Inc.

I called the shop before I did anything else. Turns out it’s not some shady resale scam. His wholesaler buys bulk units off companies that are constantly cycling their fleets, and every so often a serial number doesn’t get cleared out of the system before it hits the shelf. Not malicious, just a real cost of doing business on the used enterprise hardware side. He told me straight up he’d ship it back to his wholesaler for credit and let the wholesaler sort it out with Disney directly. I decided to give him a shot at making it right before I pushed on anything. By the time that was settled it was 6pm. Nothing more to do that day.

Day 17, July 31. Today. Went back up late morning. He had a comparable 16-inch replacement ready, smaller hard drive than the M1 Max, but that’s a non-issue, everything I run lives in the cloud anyway. I’m sitting at maybe 200 out of 512GB used right now. Storage was never the problem. RAM was the problem, and this one doubles what I had.

Drove back to the coast, spent a few hours on the beach, had dinner, then spent the rest of the night getting the new machine set up. That part’s not glamorous. Re-provisioning encrypted SSH keys and permissions for the dedicated server I run: a new machine doesn’t inherit access, so you rebuild it by hand. Reinstalling, re-authenticating, making sure the new machine’s actually trustworthy with client work before I touch anything live.

Here’s the principle underneath all four days. The machine underneath your machine doesn’t announce it’s about to fail. It just quietly runs out of room, and you find out live, mid-build, with nothing shipped.

The stealable patterns:

1. Check memory pressure before you buy, not after you crash. The lesson: Activity Monitor tells you the truth your gut can’t. Know your real number before you spec anything.

2. Organized tabs still cost you RAM. The lesson: a tab group full of dashboards you’re in and out of all day is infrastructure, not clutter, and infrastructure has a cost even when it’s useful.

3. A crash mid-build doesn’t just cost you the build. The lesson: every prompt, crash, reopen cycle is time you don’t get back, and it compounds fast when it eats your whole day.

4. Used enterprise hardware carries risk you can’t see from the listing. The lesson: ask directly whether a unit shows enrollment or fleet history before you trade anything in, and know a legit shop will make it right when it happens.

5. Getting the new machine home doesn’t mean you’re back to work. The lesson: budget real time for re-provisioning server access and permissions. It’s not optional and it’s not fast.

Nobody selling the AI dream talks about any of this. They talk about prompts and automations and passive income. Nobody tells you the thing sitting under all of it, the actual physical machine, is infrastructure too, and infrastructure fails. Building with AI isn’t free just because the software subscriptions are cheap. The real cost shows up when your hardware can’t keep pace with what you’re asking it to run, and you find out the hard way, mid-build.

My name is Adam Peters, and I’m done just unfucking the transition. Now I’m building the machine that does it at scale.