I tried to build a SaaS. I'm shipping tiny libraries instead.

For 7 days I poured energy into ChatProof — a testing framework for AI chat UIs. The problem was real: every team building Claude/GPT wrappers hits the same streaming-render bugs, and existing e2e tools weren't built for non-deterministic LLM output. I had a competitive analysis. I had a PRD. I even had a name.

Then I admitted something to myself: product/market work just isn't my strength.

I'm a builder. I love writing TypeScript. I love designing APIs. I love npm test going green. I do not love writing cold DMs. I do not love figuring out which subreddit my ICPs hang out in. I do not love crafting positioning documents.

Once I named it, the pivot was obvious.

The pivot

Instead of one ambitious SaaS, I'd ship tiny zero-deps libraries that solve specific Anthropic SDK pain points I personally hit. Each one:

< 500 lines of TypeScript
Zero runtime dependencies
MIT licensed
Published to npm
1–2 weeks of work max

The goal isn't to build a unicorn. It's to leave a GitHub trail that demonstrates I can ship real code, get organic distribution through npm + search, and let the work compound over months.

The 5 days

Day 1 — claude-stream-collector

Consume Anthropic Messages streaming events into a typed CollectedResult. Handles tool_use input JSON delta accumulation (the SDK leaves this to you) and merges cache token usage across message_start + message_delta (the SDK overwrites). ~120 lines, 6 tests.

Day 3 — claude-retry

Smart retry for Anthropic API calls. Respects retry-after headers (which the SDK's built-in retry doesn't always honor), exponential backoff with jitter, custom retry predicates, AbortSignal support. ~180 lines, 25 tests.

Day 5 — claude-pricing

Calculate Claude API cost from token usage. Bundled pricing table with smart model-alias resolution (strips date suffixes), batch API discount, session CostTracker with budget alerts. ~180 lines, 19 tests.

Three packages, ~480 lines of code, 50 unit tests. All public. All on npm.

What I'm learning

1. Match the work to who you are, not who you think you should be.

Indie Hackers and Twitter are full of advice assuming you're a generalist who loves every part of building a company. Many great engineers aren't, and that's fine. Tiny libraries are a perfectly valid path if you optimize for shipping over selling.

2. Zero-deps is a feature, not a constraint.

Every dependency is a future maintenance burden, a potential security issue, and a reason for someone to skip your package. For 100–500 line utilities, you almost never need anything but Node's standard lib.

3. Series narratives compound.

Each package on its own is a small thing. But three packages with shared types (TokenUsage flows from claude-stream-collector → claude-pricing cleanly) form a tiny ecosystem. Each new package strengthens the others.

4. Build in public ≠ build for engagement.

I posted about each release on X and 即刻. Engagement so far: zero likes, zero replies. Downloads on the first package: 129 in 7 days. People install packages they discover via search and never engage with the announcement. That's fine — the artifacts persist longer than any tweet.

5. Pivoting hurts less when you preserve learning.

ChatProof isn't dead. The painpoint research, competitive analysis, and architecture thinking from those 7 days informed every package since. Especially: I knew the streaming pain because I'd done the homework.

What's next

More small packages: claude-cache-helper, claude-tools-typed, maybe claude-prompt-toolkit. Same shape — small, focused, zero-deps. I'll keep posting about them but won't measure success in likes.

If you're stuck on an indie project trying to be a "real founder," maybe try shipping a single utility you'd actually use. You might find you ship four more before you'd have written a single landing page.

Three packages: