Building in the Margins

It’s 10:14pm on a Tuesday. My daughter is asleep. I left the office at five, was home by six, and the next three hours were the kind of time that doesn’t really belong to anything — dinner, transition, the parental handoff from day mode to whatever this is. By nine the scattered part settles. By ten I’m actually in it.

I open the Nitro 5. Three windows arrange themselves the way they always do: the editor on the left, the terminal on the right, Tower’s remote session in the corner. Tower is a Dell OptiPlex running in the spare room, accessible via Tailscale from anywhere, always on. I don’t have to be at a desk for this to work. The infrastructure runs whether I’m in front of it or not.

That’s the whole point. But we’ll get there.

What the Margin Actually Looks Like

People talk about building on the side like it’s a schedule problem. If you just blocked out two hours every night, protected it, treated it like a meeting — the implication being that discipline is what’s missing.

That’s not the problem.

The problem is that the two hours exist inside a container of everything else. The day job ends at five. Home by six. The window between six and nine isn’t free time — it’s transition time. Dinner. Kid. The mental decompression that has to happen before any real cognitive work is possible. You can’t shortcut that window. Trying to work in it produces the worst of both: you’re not present for the evening, and you’re not producing anything worth keeping.

The margin starts at nine. That’s the real number. Nine to midnight, on a good night. Less when the day was hard. More, sometimes, when something is working and stopping feels wrong.

What’s actually in front of me at 10:14pm: a PrivyBot directive that needs reviewing, a VoidDrift bug that’s been sitting in my mental backlog since Thursday, a blog post inventory with titles and no drafts, and three ideas I had during the commute home that I texted myself and will probably misread later.

The warrior session is navigating that. Picking one thing, closing the other tabs manually, and going.

The “Mostly” Energy Problem

There are two kinds of late-night sessions.

The first kind: you sit down with actual focus. Something in the day charged you up — a problem you solved, a thing that worked, an idea that clicked — and that energy carried into the night. These sessions are disproportionately productive. You find the bug in twenty minutes that you’d been describing to yourself for a week. You write a post in ninety minutes that would have taken three hours on a Saturday. The hour is sharp.

The second kind: you sit down because you’re supposed to. Because you told yourself you would. Because the project is real and the timeline matters and stopping is not an option. The energy is what I’d call “mostly” — mostly there, mostly functional, mostly able to hold a thought from one line to the next.

Mostly sessions are expensive. Not because nothing happens — things happen. Code gets written. Commits get made. The progress bar moves. But the output quality is lower in ways that aren’t immediately visible. The function that works but doesn’t quite fit the architecture. The directive that’s slightly under-specified and will need a revision pass. The blog post that says what it means but not as precisely as it could.

Mostly sessions create technical debt. Not the obvious kind — nothing breaks. The subtle kind, where everything is slightly below the standard you’d hold yourself to with sharp energy, and you don’t notice the gap until you’re looking at it two weeks later wondering why this feels off.

I’ve stopped trying to fight this with discipline. The mostly sessions still happen — you can’t always wait for the sharp ones — but I’ve learned to route them differently. Mostly energy for low-stakes work: reading, organizing, light review, scheduling. Sharp energy for anything that sets the architecture for what comes next.

You can’t manufacture sharp. You can stop wasting it on tasks that don’t need it.

What the Constraint Produces

Here’s the thing nobody says about building in the margins: the constraint makes you better at scoping.

When you have eight uninterrupted hours, scope creep is easy. There’s room for the interesting detour, the refactor that would be nice to have, the feature you weren’t asked to build but that seems like it might be useful. You follow threads because you have time to follow threads.

When you have ninety minutes, you don’t. The session has to have a goal that’s achievable in ninety minutes or the session fails. That forcing function produces a discipline that I genuinely don’t think I could have learned any other way.

My directives are precise because they have to be. An under-specified directive doesn’t get discovered until the agent has gone sideways and I’ve lost forty minutes of a session I don’t have. My test floors are real because I can’t afford to discover a fake floor later. My scope tables are explicit because I’ve paid the price of implicit scope too many times with time I couldn’t recover.

The constraints trained me. Not intentionally. Just through repetition and consequence.

The Cost Nobody Talks About

There’s a tax on this mode of working that I want to name directly, because the discourse around “building on the side” tends to skip it.

The tax is continuity.

Every session starts with a reconnect. Where was I? What was the state? What was I about to do when I had to stop? If I left clean notes, this costs five minutes. If I didn’t — if the session ended because my daughter needed something and I just closed the laptop — it costs twenty, and some of that twenty is actually reconstructing decisions I already made and don’t need to make again.

This is why I started writing state files. docs/state/current.md on every project, updated as the last act of every session. Phase. Floor. What’s next. Not for posterity — for 10pm-me three days later who needs to get up to speed in the time it takes to read four lines.

The other part of the cost is the solo problem. There’s no one to rubber duck with at 10pm. No team standup that catches the thing you’re about to do wrong. No architecture review. The accountability for decisions is entirely internal, which means the feedback loop on bad decisions is slow. You make the choice, you implement the choice, you live with the choice for two weeks before you see whether the choice was right.

This is partly why the Director → Directive → Agent structure matters to me as much as it does. Claude as the architectural layer isn’t just an efficiency tool — it’s a thinking partner in a mode where thinking partners aren’t otherwise available. The directive is the rubber duck session. Writing it forces the decision to be explicit in a way that internal monologue doesn’t.

What This Mode Is Building Toward

I want to be clear about something: I’m not trying to grind indefinitely in the margins.

The goal of the sessions is to build things that eventually don’t need sessions.

PrivyBot runs on Tower autonomously. RALPH — the persistent overseer — fires on its own, runs tasks, monitors things I’d otherwise have to check manually. ContentPipeline records, transcribes, assembles, and schedules content while I sleep. TeleseroAdmin2026 runs its own loop during business hours without me watching it. The DNC automation is on Cloud Run, stable, handling compliance checks I used to do manually.

Every system I’ve built in the margins has reduced the number of things that require me to be present. That’s the compounding. The warrior sessions are deposits. The autonomous systems are the interest.

The consulting angle I’m building toward is the same logic applied externally: I’m not selling my time, I’m selling systems that reduce the need for my time. The pitch I’m developing isn’t “I’ll do this for you” — it’s “I’ll build this for you once and it will run without me.”

You can’t make that pitch credibly without having built it for yourself first.

The Honest Frame

I’m not writing this to make the margins sound romantic. They’re not. The mostly sessions are real. The continuity tax is real. The isolation is real. The constraint that my daughter’s stability comes first — that certain risks don’t get taken, certain opportunities don’t get chased, certain all-in bets don’t get made — that’s real too.

But the margins are where I have, and I’ve stopped waiting for better conditions before building seriously in them.

The three-window setup at 10:14pm is not the setup I’d design if I were designing from scratch. It’s the setup that exists. Tower in the corner, Nitro 5 on the desk, the terminal showing a floor that’s real because I ran it myself.

It’s enough to build something from.