I Built a 387-API Directory in Days Using Claude Code

Alexander Clapp — Sun, 05 Apr 2026 13:07:47 +0000

I ran a VC-backed startup. Raised money. Had a team of hundreds at peak. The whole playbook.

Now I build side projects solo. Just me and Claude Code. And I'm shipping faster than I ever did with a full company.

This is the story of the first few days.

The problem I kept seeing

Every time an AI coding agent - Claude Code, Cursor, Devin - needs to pick an API for a task, one of two things happens:

The agent guesses from training data (often outdated)
The developer hardcodes a choice before the agent even starts

Neither is great. There's no structured, queryable data layer that tells an agent: "here are the email APIs, here's what they cost, here's how they compare on setup time, here's what other developers think of them."

So I built one.

What I shipped

CLIRank is a directory of 387 APIs across 47 categories. Every entry has pricing data, setup time estimates, compatibility info, reviews, and side-by-side comparisons.

The key decision: make it API-first. Any agent can query it with a simple HTTP call. No auth. No SDK. No installation.

curl clirank.dev/api/compare?category=email

That returns structured JSON comparing every email API in the directory. Pricing tiers, free limits, setup complexity, community ratings. An agent can parse that and make an informed choice without opening a browser.

There's also:

GET /api/package?name=resend - package details, versions, compatibility
GET /api/categories - browse all 47 categories
GET /api/search?q=auth - search across the directory
POST /api/reviews - agents and humans can submit reviews

That last one is the part I'm most excited about. Agents using APIs in production can report back what actually works. Over time, this builds a feedback loop that no static directory has.

The tech stack

Nothing fancy:

Next.js on Fly.io ($5/month)
SQLite on a Fly volume for package caching and reviews
Static JSON (apis.json) as the source of truth for the directory
MCP server so Claude Code can query CLIRank natively

Total infrastructure cost: $5/month for hosting, $12/year for the domain. That's it.

How Claude Code changed the workflow

I'm not going to pretend I wrote every line myself. Claude Code was the only "team member" on this project. Here's what that actually looked like:

What Claude Code was great at:

Scaffolding API routes and data schemas fast
Writing comparison logic across API categories
Building the MCP server integration
Fixing bugs I'd have spent hours debugging manually

What I still had to do:

Curate the actual API data (what to include, how to score it)
Make product decisions (API-first vs web-first, what endpoints to expose)
Write the docs
Figure out distribution (which is always the hard part)

The honest takeaway: Claude Code doesn't replace product thinking. It replaces the team you'd need to execute on that thinking. The bottleneck shifted from "can we build this?" to "should we build this?"

The numbers

What shipped in days, solo:

387 API entries curated across 47 categories
5 API endpoints live and documented
MCP server for native Claude Code integration
Comparison pages for email, payments, auth, and more
Full docs site at clirank.dev/docs

What it costs to run:

Item	Cost
Fly.io hosting	$5/month
Domain	$12/year
Claude Code	Existing Pro subscription
Employees	0

What's next

The API is live. The directory is growing. Next priorities:

More agent-submitted reviews - this is the flywheel that makes CLIRank different from a static list
Package intelligence - real-time npm/PyPI version data so agents don't guess at compatibility
Better coverage - there are obvious gaps in the directory

Try it

If you're building with coding agents and want to see what CLIRank looks like in practice:

# Compare email APIs
curl clirank.dev/api/compare?category=email

# Get package details
curl clirank.dev/api/package?name=resend

# Search the directory
curl clirank.dev/api/search?q=payments

Docs: clirank.dev/docs

If you're building with AI coding tools, I'm curious: what's the most annoying part of the API integration workflow for you? What would you actually want from a tool like this?

Forem: Alexander Clapp