One desk, many hats — a solo builder cutting away the roles that don't matter

The One-Person Workweek: How Solo Founders Actually Get Things Done

A solo founder wakes up already behind. There’s the product to build, the customers to answer, the books to square, the marketing nobody’s doing, the bug that shipped last night. Six jobs, one seat. Most people call this a focus problem and reach for a timer or a todo app. It’s not a focus problem. It’s a structure problem. You’re not failing to do six things at once because you’re undisciplined — you’re failing because six things are the wrong number. The solo founders who make it work don’t get faster at juggling. They stop carrying five of the six balls. ...

Quiet leverage for the solo builder

How to Get Your First Users as a Solo Builder (Quiet Leverage, Not Cold Outreach)

Build the thing, and a certain silence follows. You ship it. You tell a few people. And then — nothing. No users, no feedback, no sign that anyone heard. Most solo builders assume this means the product failed. Usually it means something simpler: you built it, but you never actually distributed it. This is the part nobody writes about, because the people who write about building are good at building, not at the awkward part that comes after. Distribution is not another build skill. It’s a social skill — which is exactly why introverts assume they’re bad at it. They’re not. They’ve just been handed the wrong playbook. ...

Reuse or rebuild — two diverging paths, a custody decision

Reuse vs Rebuild: The Custody Rule for Solo Builders

The build-vs-buy debate is the oldest argument in software, and for years it was boring math: build if the license would cost more than the engineering. AI broke that math. When a solo builder can scaffold in a weekend what used to take a quarter, the cost case for reusing something — a library, a SaaS tool, an open-source project — quietly stopped being the deciding factor. What replaced it is a quieter question: who owns this thing when it matters? That’s not a cost question. It’s a custody question — and it’s the one that actually decides, in practice, whether your one-person company survives its third year. ...

Solo founder or co-founder — a decision rule

Solo Founder vs Co-Founder: A Decision Rule for the AI Era

For most of startup history, “who’s your co-founder?” wasn’t really a question. It was the first box on a checklist, right after “what’s your idea?” A single founder who went it alone would hear the same first line every time — you’ll wish you had a team — as if a co-founder were insurance you’d bought, not a person you’d now be legally and emotionally tied to for a decade. ...

A single maker at a bench, assembling a physical device

Building Hardware Solo: The Maker Room Most Builders Skip

The solo-builder conversation is almost entirely about software — code, agents, apps. And every time, the same assumption slips in: that “one person can now ship” only applies to things that compile. That assumption is quietly wrong. The same cost collapse that flattened software shipping is happening on the hardware bench, a few years behind and mostly unnoticed. A single maker with a fifteen-dollar microcontroller, AI-assisted design tools, and on-demand fabrication can now assemble, in a weekend, what once required a team of engineers and a factory. ...

Three ways to build, three different jobs

No Code vs Vibe Coding vs Real Code: Which One Should You Actually Use?

No code vs vibe coding vs real code: the real difference The 2026 building scene offers three overlapping paths, and the internet has opinions about all of them. No-code is “the future” or “a toy.” Vibe coding is “magic” or “a disaster waiting to happen.” Writing real code is “the only serious option” or “a waste of time now.” They’re all being argued about the wrong way, because they’re not rungs on a ladder — they’re three different tools for three different jobs. The real question isn’t “which is best.” It’s “which failure mode can you afford?” Here’s the honest read. ...

A year of shipped things, side by side

One Year of Building: What Actually Compounds (and What Doesn't)

A year ago this site was an empty scaffold and a promise. A year of building later, there’s a body of work: things shipped, things broken, things learned. This is the honest ledger of that year — what actually compounded, what quietly didn’t, and the one insight I’d reread on day one if I could. What actually compounded The streak, not the sprint. The single biggest lesson, and the least glamorous. Consistent small sessions beat heroic weekends every time, because the streak keeps the context warm and the weekends keep relearning it. I’d heard this for years. I didn’t believe it until I felt the difference. ...

Solo founders are winning

Solo Founders Are Winning — Here's What Changed

Until very recently, “solo founder” was a phrase investors said with a wince. It read as couldn’t find a co-founder — a red flag on a term sheet, a polite rejection from an accelerator. Going it alone was the backup plan, not the point. That stigma is now dead, and it didn’t die by argument. It died the way stigmas actually die: the numbers stopped supporting it, and the people closest to the numbers changed their minds. This is the receipts post — the outcomes that are now public, and what they actually prove. ...

One small completed thing, week after week

The 'Ship One Tiny Thing' System (How Small Wins Actually Compound)

Everyone wants the breakthrough — the big launch, the viral hit, the overnight success. And everyone quietly knows that’s not how it works. What actually works is so boring it gets ignored: ship one tiny thing, every single week, without fail. The system doesn’t sound impressive. That’s the point. It’s the unglamorous, compounding engine that separates people who have a body of work from people who want one. Here’s the whole thing. ...

A focused AI coding toolchain, not a drawer full of tools

The AI Coding Stack I Actually Use (and Why I Stopped Swapping Tools)

There’s a question every solo builder gets asked constantly, and it’s the wrong one: “which AI coding tool do you use?” The question implies the tool is the bottleneck — that if you just found the right assistant, the work would get easier. It won’t. The tools are roughly equal now, and the gap between them is smaller than the gap between using one well and using ten badly. This post is about the stack I actually settled on, and the part of the story that usually gets skipped: the biggest win wasn’t the tool, it was stopping the search. ...