Making Room: How Claude Code Changed the Way I Operate

Our team has been nudging me to contribute to our Substack for a while. I kept putting it off, not because I didn’t have anything to say, but because I couldn’t figure out what my angle was. Then I accidentally stumbled into building software for the first time in my life, and here we are.

I’m Asa, COO at Near Space Labs. My days are contracts, OKRs, vendor negotiations, team alignment, and the thousand tiny fires that come with scaling a company from 12 to 80 people. I don’t write code, but I’ve been around engineers long enough to understand how systems fit together, but anything I’d write myself would be garbage.

Our engineering team has been using Claude Code for a while. They love it. I’d hear them talk about it, see the demos, nod along. But I never opened it myself.

Then I read Ethan Mollick’s piece, “Claude Code and What Comes Next” (thanks @Ned for sharing). He had Claude Code autonomously build an entire startup, working on its own for over an hour, generating hundreds of files, deploying a live website. It was wild. But the part that stuck with me was his observation that this kind of capability is still locked behind a programmer’s interface. He basically said: this is coming for everyone, but right now you need to be technical to use it.

I’m not technical. But I am stubborn. So I opened it up.

I started with toys. A workout tracker. A visualizer of gravity-assist trajectories, the kind where a spacecraft slings around a planet to pick up speed. And a choose-your-own-adventure story generator for my daughter. She’d pick a topic (her first choice: babies) and it would narrate a story, then pause with a question: “What did the baby find under the crib?” She’d shout “FARTS” and the story would roll with it. I even wired up ElevenLabs to give it a warm, friendly voice. She loved it. I was hooked.

Each one was a small experiment, and each one taught me something about how to talk to the tool, how to frame a problem clearly enough that it could give me something useful back. I got a little better each time. I’m not at the level where I describe something once and get a polished result, what the experts call “one-shotting.” But the gap between “idea” and “thing that works” has collapsed in a way I genuinely didn’t expect.

The operator’s dilemma

If you’ve worked at a startup, you know the feeling. Constant chaos. Limited resources. An endless list of things that could be better, smarter, faster, but not enough time or people to make them all happen.

Sam Altman distilled his operating advice to two words: focus and intensity. He’s right. But the dirty secret of startup operations is that focus requires ignoring things that genuinely need fixing. You’re not choosing between good and bad. You’re choosing between important and also important. The small stuff slides, not because you don’t care, but because there’s no other option.

Ben Horowitz put it differently in The Hard Thing About Hard Things: when you’re a startup executive, nothing happens unless you make it happen. You have to take on eight to ten new initiatives a day or the company stands still.

But with Claude, that calculus is changing for me.

Where it gets real

The toys were fun, but they weren’t the point. What I actually needed was to fix things at work that had been bugging me for months. Not big strategic problems (yes, we have those too) but small, specific friction points that are unique to how Near Space Labs operates. The kind of thing you’d never find an off-the-shelf tool for because no one else has exactly the same challenges. Here are a few examples:

The hard drive problem. When we fly our stratospheric vehicles, we collect enormous amounts of imagery data. Everything downstream is automated, but the upload process still starts with someone physically plugging in a drive and remembering to click a button. In about two hours, I built a listener that detects when a new drive is connected and sends a Slack notification with an upload button. Plug in, get a message, click, done. Making room in someone’s day by removing a task they shouldn’t have to think about.

The NDA bottleneck. Our bizops person was the single point of contact for every NDA, not because she was slow, but because we only have a limited number of Dropbox Sign accounts. Every time someone needed to send a standard NDA, they’d message her, she’d log in, fill it out, kick it off. Now anyone in the company can go to a Slack channel, type an email address, and the NDA goes out automatically. Making room for her to focus on work that actually needs her judgment.

The OKR tracker. We finalized OKRs in January and I wanted a clean way to share them. I looked at off-the-shelf tools but they were bloated and expensive for what we needed. A Google Sheet would work but lacked the visibility I was after. Two hours later: a simple, purpose-built OKR site where the whole company can view and track goals. Exactly what we needed, nothing we didn’t. Making room for alignment without adding another login or another subscription.

The docs rewrite. We have public developer docs for our imagery APIs. I downloaded all of it, fed it to Claude, and asked it to build me a map using our data. Then I asked it to suggest changes to the documentation based on the challenges it ran into while building. It was like having a fresh set of eyes go through the entire developer experience. The result was a clean rewrite of our docs.

I know there’s a lot of noise right now about AI killing SaaS. I don’t buy that. Slack, Atlassian, the tools we run our business on aren’t going anywhere. What’s changing is the stuff around the edges. The gaps between your tools. The workflows are too specific to your company for anyone to build a product around. The things you used to just live with because the cost of fixing them was too high. That’s what’s opening up.

The part that’s hard to measure

Operating a startup used to mean constantly choosing between fixing the small stuff and focusing on the big stuff. You almost always chose the big stuff, and the small stuff quietly degraded the experience for everyone. A clunky process here, a manual handoff there. None of them worth a sprint, all of them quietly costing you.

That tradeoff is dissolving. The small stuff doesn’t need a ticket anymore. It doesn’t need to wait for an engineer’s free afternoon. It needs a couple of hours and a clear description of the problem.

The result isn’t just efficiency. It’s room. Room in your day. Room in your head. When you’re no longer carrying around a mental list of “things that should be better but can’t be right now,” you actually have space to focus with the kind of intensity Altman is talking about. On strategy, on people, on the problems that only you can solve. That feels like a genuinely different way to operate.

A partnership, not a takeover

I want to be clear about something: I’m not doing this alone, and I’m not replacing anyone.

When I built our OKR tracker, it worked great locally. But the moment I wanted to deploy it so the whole company could see it, I needed help. Our engineering team stepped in, helped me with auth so we could protect company IP while still giving everyone visibility, and set up the infrastructure to host it properly. That collaboration is the model. I can build the thing, but shipping it safely into a shared environment is a different skill set entirely.

What’s been encouraging is the energy going the other direction too. Our head of product is now using Claude to visualize roadmaps and flight plans. Our head of finance built himself a tool to stress-test variables in our financial model without wrestling with a massive spreadsheet. These aren’t developers. They’re operators who now have a new lever to pull.

The actual point

Day to day, running a startup is really about resource management. Making the most of limited people, limited time, and limited money. Every manual process you tolerate, every tool you can’t afford, every optimization you defer, it all has a cost.

Claude Code doesn’t eliminate all of those compromises. But it removes a remarkable number of them, remarkably quickly, for people who aren’t engineers. And the thing you get back isn’t just time. It’s room. Room to think about the work that actually moves the company forward. Room to be the operator your company needs you to be instead of the one buried in the stuff that should have been fixed six months ago.

That feels like a big deal to me and I’m curious if others are feeling it too.

• Where in your operations are you still living with friction that should have been fixed six months ago?

• If you’re thinking about trying this yourself, what are your biggest questions about getting started?

We are looking into how we can roll our Claude Code more broadly for company use. If you’re interested in playing around, please reach out to me directly at Asa@NearSpaceLabs.com. I would love to chat more!