Solo founder, AI-augmented by design.

The category of objection I get most

When I tell a CISO that BleedWatch is solo-built, the response splits cleanly into two buckets.

Bucket one: "Then how do you respond to an incident at 3am?" Bucket two: "Then how do you ship faster than the F500 vendors who have 200 people on this problem?"

The second question is the interesting one. The first is a procurement gate I'll address through SLA structure and a runbook — fair, important, not philosophically deep. The second is asking something real: how does a single person move faster than a team, and why should the customer believe that's stable rather than a moment of luck?

I've been thinking about this for the entire build, and the answer I've landed on isn't "AI replaces engineers." That phrasing is wrong and the founders I respect don't use it. The answer is AI replaces the friction that used to require a team to overcome. Two different things.

What the operating model actually looks like

A typical week on BleedWatch development:

• Spec drafted by me, audited by Claude Opus, contested by Codex (GPT-5.5) and Gemini Pro before a single line of implementation lands. The contest is real — these models disagree, often productively, on architecture choices.
• Implementation done in plain TypeScript with Cursor + Claude Code. I drive. The model fills in the boilerplate I would have typed slower. Productivity multiplier is real but bounded — about 3-4x on greenfield, closer to 1.5x on refactors of legacy code.
• Code review done by me and two reviewer models in parallel. Disagreements between reviewers force me to read more carefully, not less. The models are imperfect; that's the point. They imperfect in different directions.
• Production ops automated through GitHub Actions deploys, Cloudflare Worker KMS proxy, Hetzner Falkenstein for the primary tier. No human in the deploy loop unless I push the wrong button.

This isn't replicable yet by every founder. It depends on having internalized the model's strengths and weaknesses through about 18 months of daily use. The methodology compounds. I expect a solo founder starting today to be 6 months from this kind of fluency.

Garry Tan's "make something people want" hits harder solo

Garry Tan's recurring point at YC events is that founder velocity comes from getting closer to the customer than anyone else can. The corollary nobody states is that a team adds layers between the founder and the customer. A solo founder has zero layers. Every email, every Slack support thread, every sales call, every angry tweet — it all hits the same inbox. That's exhausting. It's also clarifying.

I have a much sharper sense of what BleedWatch needs to be next quarter than I would if I had a PM filtering signals for me. That's not a brag. It's structural.

The trade-off: I do not scale linearly. By design. The question I'm holding off on for as long as possible is "when do I hire?" — every hire adds a layer, and the layer compounds in the wrong direction unless I find someone who can also operate solo-style. Most candidates can't, not because they're bad, because the discipline is unusual.

Where AI helps less than people think

Two areas of weakness I want to name honestly, because the puff pieces never do.

Security review of detection patterns. The model is good at "is this regex syntactically correct?" and bad at "does this regex catch the failure mode we actually care about?" The second question requires a feel for adversaries that I think comes from having been on both sides of one. The model doesn't have that. So my detection patterns get reviewed by me, hard, then by Codex with a specific prompt focused on bypass scenarios, then by Gemini with a prompt focused on false-positive risk. Three passes, none of them sufficient alone.

Customer empathy in product copy. The model can write polished marketing copy. It cannot tell when polished marketing copy is exactly the wrong thing to ship. There's a register that says "this vendor is in your head, not selling at you," and the model overshoots in the selling direction by default. I keep this in my own pen.

Inspirations I'll name explicitly

Dario Amodei's "moment of danger" framing — that the offense-defense gap is widening and the window is narrow — is the explicit operating premise of BleedWatch. We build for the defender's side of that asymmetry, knowing the offensive side is moving faster.

Paul Graham's "Maker's Schedule, Manager's Schedule" essay from 2009 is the structural argument for not having a team yet. I can spend three days straight in maker mode because there's nobody requesting a 10am sync. That depth, sustained, is the only way detection-engine work actually gets done.

Garry Tan's "founder mode" framing applies even with a team of one — it means staying in the work, owning the call, refusing to outsource taste. I'll fail at this when I hire. I want to delay that failure as long as possible.

The 2026 thesis

A small number of founders are going to build credible vertical SaaS in 2026 with operating leverage that doesn't match any team-size expectation customers were trained on. Cybersecurity is one of the verticals where this is most true, because the work is judgment-heavy on detection design and automation-heavy on the rest. AI gets the second part for free. The first part still rewards a single sharp mind more than a committee.

If you're a CISO evaluating BleedWatch, the right question isn't "what's your headcount." The right question is "show me three detection decisions you made this quarter and the reasoning behind each." I will. The reasoning is the product.