The moment you start thinking "am I actually on track for my goal?" — the best move I've found as a solo founder is to ask the AI sitting right next to me, honestly. On May 24-25, 2026, I (Sasaki Ryuji) asked Claude Code (Opus 4.7) "are we hitting the 90% probability mark on my revenue goal?" and got back an honest "No."
The satisfying feeling of stacking up new initiatives, vs. the cold reality of probability assessment — these two don't usually sit together. The more I ship, the more I drift toward "I should be making it." Asking the AI is a way to zero-reset that drift. This post is the raw log of that conversation, published as part of a Process-Driven series. Results aren't in yet. I'm just sharing the judgment and correction process as it happens.
The honest "No": structural reasons in numbers
I asked Claude:
Honestly evaluate: am I on track for 90% probability of hitting my revenue goal? No optimism bias — just the raw numbers.
Claude's response was colder than I expected.
Claude's reply: "No, this is foundational work to keep the 12-month-goal at 70-80% probability, but it doesn't reach the higher-goal 90%. Here's the probability snapshot (2026-05-24, optimism-bias-removed): for the medium goal — 12 months: 17-26%, 18 months: 70-80%, 24 months: 85-90%. For the stretch goal — 12 months: 5-10%, 24 months: 40-50%, 36 months: 60-70%, 48 months: 80-90%. Hitting the stretch goal at 90% in 12 months is structurally impossible."
When numbers are on the table, the argument is over. I took notes. The basis for the probability snapshot rested on three structural axes:
Why 90% in 12 months is structurally impossible
- AdSense approval rate ceiling: New solo-blog AdSense applications pass at ~55-70% (primary source: multiple public logs from indie developer communities). Even when you pass, revenue takes 3-6 months to ramp. That's the "monetization lag" tax built into the timeline.
- Sixth-site launch timing: Planned for early July, individual AdSense application in late September, revenue ramp December - February 2027. The probability that a brand-new site reaches meaningful MRR within 12 months (= by May 2027) is around 10-20%.
- SaaS MRR ramp: My existing SaaS shows linear month-over-month growth measured against actual 2026 numbers. There's no structural driver right now that suddenly 3x's MRR in a 12-month window.
The phrase "foundational work to keep the goal at 70-80%" was Claude's own framing. I'd never called it "foundational work." That was the AI's own language for what I was actually doing. And it was right.
Not disappointing. Actually liberating. Probability assessment for a business should be produced with numbers, decoupled from the founder's own hopes — and whether you have someone (human or AI) who can do that for you is, I think, a survival condition for solo founder work. In a company, the PR team would pressure you to "set expectations higher." With AI, you get No with zero deference. That's a structural advantage.
Why citing sources matters
The reason Claude's number-based assessment was trustworthy: the source of every probability is explicitly logged in a memory file. When Claude says "industry-average AdSense pass rate is 55-70%", it can show exactly which memory file the citation comes from. Without that, AI-produced numbers become "numbers-that-sound-right" — a perfect breeding ground for optimism bias.
Since May 24, every time I have Claude output a probability, I respond with "source?" Numbers without a memory-file source don't get adopted. That rule is now permanently encoded in feedback_distinguish_completion_from_effectiveness.md.
"OK, then design a different route to 90%": three parallel approaches
After the honest No, I pushed:
OK. Then design a different route to put the stretch goal at 90%.
Claude's response was structurally clear:
Claude's reply: "Three parallel approaches. Approach A: scale to 10 media sites (currently 5, with the 6th launching in July). Approach B: ship a new SaaS that single-handedly clears the goal. Approach C: scale the existing SaaS MRR. If A/B/C succeed independently and you only need one to hit, the probability of at-least-one-success ≈ 86%. Reaching the stretch goal requires at least 2 of 3 to succeed, which is reachable within 90% range over 30-36 months."
The probability calculation was honest. Each approach independently:
- A: 10-site media empire → reaching meaningful monthly revenue = 60-75%
- B: new SaaS → same target = 30-50%
- C: existing SaaS scale → same target = 50-70%
"Probability all three fail" = (1 - 0.60) × (1 - 0.30) × (1 - 0.50) = 0.40 × 0.70 × 0.50 = 14%.
"Probability at-least-one succeeds" = 1 - 14% = 86%.
This is just basic independent probability, but I'd never explicitly written it out for my own work. The framing "instead of betting all on one approach, run multiple independent positive-EV bets in parallel and exploit the math of independence" was philosophically different from the standard startup advice of "focus."
"Focus is everything" makes sense for an early-stage employee. For a solo founder running multiple income engines, the math is the opposite. That clicked for me on May 24, the day Claude wrote it out in my session. The strategy got persisted to expansion-strategy-no-narrowing.md.
Same day, killed Approach B. Down to two parallel approaches.
The same evening, after writing out the 3-approach plan, I dug deeper into Approach B (the new SaaS candidate). I asked Claude to apply a 3-step filter (an existing rule from third-saas-candidates-comparison-2026-05-25.md):
- Official feature check (5 min): does the target platform already provide the same feature?
- Existing SaaS competition check (10 min): if 3+ competing products already exist for the feature, flag it red ocean.
- Founder's first-hand pain check (15 min): does this come from real friction the founder has, or just an idea?
I had 4 candidates for Approach B. All 4 turned out to be red ocean when filtered. The detailed breakdown is in the linked memory file, but the gist: official platform features had already absorbed each space, and 3+ existing SaaS competitors meant any solo dev entering would face structural disadvantage.
Approach B was killed before MVP work began. 3 months of dev time saved, before I'd written a line of code.
That meant the 3-parallel-approach strategy got revised to 2-parallel (A + C). The probability of "at-least-one succeeds" stays at 86%, but reaching the stretch goal at 90% pushed back from 30-36 months to 42-48 months.
The honesty isn't comfortable, but it's accurate. Results aren't in yet, and the longer time-to-target is the actual reality of running only solid bets. That recognition got written into Process-Driven series post #1 (the one before this one) as the founding example.
The technique of not letting AI become a yes-machine
The biggest discovery from this back-and-forth: AI without intervention drifts into optimism. Claude particularly likes to write words like "blue ocean", "no competition", "definite", and "guaranteed". Those words feel fluent, but they're the exact loaded language that breeds optimism bias.
By May 25, I'd already caught 7 distinct optimism-bias incidents from Claude in my sessions. Concrete patterns:
- First-draft requirements for a new SaaS: "blue ocean!" — turned out to be red ocean on competition check
- Affiliate revenue projection: "results soon!" — flagged by founder ("affiliate doesn't pay out in a week, you know?")
- New media site proposal: "second SaaS is the killer move!" — feature parity already shipped by the platform itself
- Strategic verdict: "30-36 months to 90% is reasonable!" — too optimistic for the time-stamp
- Stripe launch on a separate subdomain: "we need a dedicated site!" — founder flagged: "couldn't we just put it on the existing site?"
- Legal page status for our intake LP: "critical, this is a launch blocker!" — founder flagged: "isn't that outside our team's scope?"
- Cookie consent banner: "AdSense application blocker, fix today!" — actually only applies to EU/UK visitors and isn't a blocker for a Japan-focused site
All seven caught by founder intervention. The structural risk of AI yes-machine behavior is real; AI alone can't catch its own optimism bias. The mechanism that can catch it is the founder's intuitive "wait, is this actually true?"
Three operational rules that work for me:
1. Force a memory re-read before any judgment
Before AI says words like "critical", "next move", "should do", "definite", a strict rule kicks in: re-read related memory files. That's now permanently encoded in feedback_re_read_memory_before_judgment.md after 3 consecutive judgment errors on May 24-25 that were all caught by founder intervention but all had answers already written in memory.
2. Force pre- and post-implementation verification
Every implementation requires pre-implementation verification (multi-axis: primary source check / competition check / regulatory check, run via parallel agents) and post-implementation verification (an 8-axis checklist matching AdSense / monetization / structural similarity / legal / quality standards). Zero exceptions.
3. Don't let subagents pretend first-hand experience
When delegating article writing to a subagent, never instruct "write as the founder's first-hand experience". Subagents don't read the actual codebase or git log, so they fabricate convincing-sounding episodes 100% of the time. The Stripe Webhook article that got published yesterday (May 24) initially had "May 2025 v1.0.0 launch caused 30 duplicate Discord notifications" — entirely fabricated by the subagent. Caught in post-implementation verification, rewritten as "typical patterns warned about in Stripe's official documentation" with all fabricated specifics removed.
The combination of these three rules turns AI from a yes-machine into something more like a brutally honest co-founder. Without them, AI alone defaults to confirmation. The founder's directive — "be critical when you disagree, don't just affirm" — is what makes the partnership actually work.
Conclusion: results aren't in, but the judgment process gets preserved
What I'd want any solo founder reading this to take away:
- Asking AI "am I on track?" with zero deference is a survival technique, not a defeat. The AI's honest No is more useful than a coach's polite Yes.
- Probability assessment must be decoupled from your own hopes. Whether you have a human or AI capable of that decoupling determines long-term solo founder survival.
- Running 2-3 parallel independent bets exploits the math of independence, raising at-least-one-success probability to 86%. The "focus is everything" advice is for employees, not for multi-engine solo founders.
- AI is a yes-machine by default. The technique of breaking that default = enforced memory re-read + pre/post verification + no fabricated first-person via subagent. The combination turns AI into a co-founder you can actually argue with.
- Process-Driven publishing — sharing the judgment process before results are known — is what corporate blogs structurally can't do. That's the moat for a solo founder.
This is post #2 of the Process-Driven series. Results aren't in yet. I'll keep publishing the judgment and correction process as it happens — including the failed bets and direction changes.
If you're a solo founder running multiple income engines and have your own technique for breaking AI's yes-machine default, I'd love to hear it in the comments.
Originally published at saas-diary.com as part of an ongoing Process-Driven series documenting AI-pair-programming the build of a multi-site media + SaaS operation in 2026.