Nightwatch: What I Built When I Needed Someone to Work While I Sleep

Every evening I'd close my laptop with a shorter list than I started with, which sounds like success. Except there was always a second list. Not the strategy list, not the calls-and-decisions list. The other one: check GSC for ranking shifts, audit the post that went live Tuesday, process the LinkedIn notifications that might actually matter, summarize the three research threads I started last week and never finished.

That list never got shorter. It just accumulated.

The tasks weren't hard. They didn't require judgment in any real sense. They required sitting at a computer and doing them. But I was done. The day was over. And I didn't have anyone to hand them to.

So I built a system that works while I sleep. I called it Nightwatch. This is what it actually is, why I built it the way I did, and what I learned that I didn't expect.

The Actual Problem Isn't Time

Most solo founders frame the constraint as time. There isn't enough of it. That's true, but it misses the deeper issue.

The real constraint is sequential execution. You do one thing, then the next thing, then the next. Everything waits for you to be present. The monitoring task doesn't run until you open the tab. The research doesn't get synthesized until you're sitting with it. The briefing doesn't exist until you build it yourself, which means it takes the first hour of your morning.

There are two kinds of work. Active judgment work: calls, strategy, writing, decisions, anything where your specific knowledge and experience is the irreplaceable input. And passive execution work: monitoring, research aggregation, synthesis, formatting, tracking. Passive execution often doesn't need you. It needs someone with instructions and a process.

The problem for a solo founder is that there's no one else. So passive execution runs on the same schedule as judgment work, in the same sequential queue, at the cost of everything else.

A properly designed autonomous system breaks that constraint. It runs passive execution on a parallel track, asynchronously, while you do the rest of your life. The queue doesn't care if you're asleep.

What Nightwatch Actually Does

The physical setup is a Mac Mini sitting on my desk at home. Always on, always connected. It runs an AI orchestration layer called Orchestra, which manages a queue of tasks I push to it during the day.

During normal working hours, when I hit something that belongs on the passive-execution list, I queue it instead of doing it. That takes thirty seconds. The task goes into Orchestra with whatever context it needs to run. Then I move on.

Overnight, Nightwatch's agent loop processes the queue. It runs Google Search Console monitoring to flag significant ranking changes. It runs content audits on posts I've tagged for review. It pulls and summarizes research threads. It checks for things I've asked it to watch. Each task runs with whatever tools it needs: API calls, web fetches, data processing, write operations.

By morning, the outputs are in a briefing file. Not raw data. Not a pile of API responses. Already synthesized, already prioritized, already written in plain language. My first act of the day is reading 200 words and deciding what to act on.

Here's a concrete example. On Tuesday last week I opened the briefing and saw that one of my posts had dropped eleven positions overnight. The briefing included the trend over the past week, the specific SERP feature that had shifted, and two other pages that showed similar patterns. It took me ten minutes to read. It would have taken 45 minutes of manual GSC digging to find the same information, and I probably wouldn't have connected the pattern across the three pages.

That's the delta. The information is the same. The time cost is not.

The engineering underneath this isn't glamorous. macOS sleep states are not friendly to overnight processes. launchd requires precise configuration to keep agents alive and restart them on failure. API rate limits hit differently at 2am when you can't intervene. Error recovery has to be designed for zero-human environments. The first version of Nightwatch "ran overnight" in the sense that it sometimes worked and I found out what failed in the morning.

The version that's useful handles every failure mode before you go to sleep. That took months to build, not days.

What You Actually Build vs. What You Think You're Building

Three things I got wrong when I started, and what I understand now.

The execution environment is the product. I went into this thinking the AI models were the hard part. They're almost a detail. What you're actually building is a reliable process that can run for eight hours without a human checking on it: with retries, graceful degradation, structured output, and error logs you can read in the morning to understand what happened. The AI is the worker. The environment is the job site. You have to build a job site that doesn't fall apart.

Passive-execution tasks still need design. "Have the AI summarize my GSC data" sounds like a five-minute setup. It isn't. You have to define what a useful summary looks like, what signals matter and which don't, what format makes it fast to read, what context the agent needs to avoid producing garbage, and what happens when the data is ambiguous. This is the same discipline as writing a clear SOW for a human contractor. The AI doesn't fill in what you didn't specify. It makes something up.

The system teaches you what you actually want. My first briefing file was 800 words. I never read the whole thing. Not once. I kept meaning to, and I kept skimming it and closing it. That's information. The system was reflecting my priorities back at me, and my priorities didn't match what I thought I'd queued for. Now the briefing is 200 words and I read every word every morning. Nightwatch didn't just save me time. It forced me to get specific about what I actually need to know.

The Broader Point: Leverage Without Headcount

I want to be direct about what this isn't. This isn't about replacing human work. Most solo founders don't have humans doing their monitoring and research layer. The alternative to Nightwatch isn't an analyst. The alternative is me doing it manually, inconsistently, at the cost of judgment work.

What autonomous systems do for one-person businesses is make time non-sequential. Your day is your day. The parallel execution track runs while you sleep, while you take a walk, while you're on calls. The passive work doesn't wait in your queue anymore.

The question worth sitting with isn't "should I build something like this?" It's "why is this still unusual?" The models are good enough. The orchestration infrastructure exists. The tooling is accessible to a technical founder. What's missing is the willingness to treat autonomous execution as a system design problem rather than a prompt engineering problem. You have to build the environment, not just the prompt.

Nightwatch isn't magic. It's a well-designed process with an AI execution layer underneath. The design is the hard part. The AI is the labor.

What Changed

I start every day having already done something. Not a lot. A briefing. A set of audits. A research thread that got processed while I was asleep. Consistently, every morning, without it costing a single minute of my active time.

That compound effect is real. The days don't start with discovery anymore. They start with deciding.

Next post in this series: what I got wrong the first time, and what I'd tell someone starting from scratch. The specific failure modes, the specific fixes, and the parts I'd design differently if I were starting today.