What Memorial Day Means When You Are the Whole Company

At a normal job, the long weekend is easy. Someone sets up the out-of-office reply, the Slack status goes to a beach umbrella, and that's it. The machine keeps running without you. You're allowed to go.

Solo founding doesn't work like that.

There's no Slack going quiet — or rather, it goes quiet because you're the one who would have been posting in it. There's no team to hand off to. No manager to tell you it's covered. The permission to stop has to come from yourself, and that turns out to be a genuinely hard thing to issue.

The Cognitive Load Doesn't Pause

I've tried to take long weekends the wrong way enough times to know what that looks like. You close the laptop but you don't stop running the list. Is the cron job going to fire on schedule? Did I get back to that email? Should I check the deploy? The holiday happens in your physical location but not in your head.

This isn't about being a workaholic. It's about the structural difference between having a job and being the entire operation. When you have a team, the company continues without you — and that fact, more than any specific work item, is what lets you actually rest. When you're the whole company, you carry the state of everything. There's no external system holding it while you're gone.

Permission Is the Real Problem

I think about this differently now than I did in the early years. The problem isn't that I can't stop working — it's that I haven't decided to. That sounds like a small distinction but it's actually the whole thing.

When you're at a company, decisions about coverage and time off get made institutionally. You're given permission to be away. As a solo founder, no one gives you that. You have to take it.

The mental shift that helped me: I started treating rest as an operational decision, not a reward. Founders who run themselves into the ground aren't more dedicated than the ones who pace themselves — they're just making a different structural choice, one that usually has worse outcomes over any meaningful time horizon.

What I've Actually Figured Out

Practically: I stage things ahead of long weekends now. Not because I'm trying to perfectly simulate having a team, but because reducing the cognitive load of re-entry is worth the setup cost. The cron jobs are tested. The posts are queued. The things that can be decided in advance are decided.

Then I let it run.

The other thing: I've stopped treating it as binary. It's not "completely offline" vs "basically working." That framing sets me up for failure every time, because something will always come up that feels important. The actual skill is deciding what kind of thing actually warrants attention over a holiday weekend — which is almost never any of it — and what can wait until Tuesday.

I've had exactly one genuine emergency in ten years that couldn't have waited three days. Most of what feels urgent is anxiety dressed up as importance.

What the Holiday Actually Means

Memorial Day is a good day to think about what you're building and why. Not in a productive sense — not to make a list or run a strategy session — but in the quieter sense of: is this sustainable? Are you building something you can still be doing in five years?

I've watched solo founders burn out not because the work was too hard but because they never gave themselves permission to not be working. The studio ran, technically, right up until it stopped, and then it stopped completely.

That's not what I'm building. I'm building something that's meant to last — which means it has to include time when I'm not working on it.

So: the blog posts are queued. The cron jobs are running. The products will do whatever they're going to do.

I'm taking the weekend.