1
0 Comments

I built a sales intelligence tool for AI agents, here's what I learned about going JSON-first

Hey IH πŸ‘‹

I've spent the last several months building Sales Stack β€” a pay-as-you-go sales intelligence platform that lets AI agents search 300M+ profiles, enrich contacts, scrape pages, and pull LinkedIn data, all from a single MCP server or REST API.

No API keys. No subscriptions. No infrastructure.

Just... credits that never expire, and JSON that drops straight into Claude Code, Codex, or Clay.

Why I built it

I kept watching sales teams and founders juggle 4–5 different tools for prospecting: one for lead gen, one for enrichment, one for scraping, one for LinkedIn data, one for automation. Each with its own API key, its own subscription, its own stale database.

Meanwhile, the AI agent ecosystem was exploding. Claude Code, Codex, Clay β€” people are building outbound workflows with agents now. But none of the legacy sales tools were built for agents to consume. They were built for humans clicking buttons in dashboards.

So I thought: what if one console could do all of it, return clean JSON, and charge you only when you actually use it?

The 5 engines I shipped

  1. Lead Generation (3 credits) β€” Filter 300M+ profiles by seniority, industry, department, etc.

  2. Data Enrichment (2 credits) β€” Turn a partial email or name into a full profile (title, phone, LinkedIn, company)

  3. Web Scraping (1 credit) β€” Extract clean markdown/HTML from any URL, with proxy + dynamic rendering

  4. LinkedIn Intel (2 credits) β€” Pull profile data, company info, and post engagement

  5. LinkedIn Automation (10 credits) β€” Connect your LinkedIn account for visits, connection requests, and messages

What I learned building it

1. "Agent-friendly" is a design philosophy, not a feature. It's not enough to have an API. The output has to be JSON-first, predictable, and structured so an agent can parse it without human intervention. That meant rethinking response schemas from the ground up β€” every field an agent might need, nothing it wouldn't.

2. Pay-as-you-go is harder to build but easier to sell. Subscriptions are easier to model financially. But for sales prospecting β€” where you might search 50 contacts one week and 0 the next β€” credits that never expire just feel fair. It's been the single biggest driver of signups.

3. "No API keys" removes the #1 friction point. The MCP server authenticates with email + 6-digit code. No key management, no token rotation, no .env files. You add the server to Claude Code and just ask in plain English: "Find VP-level sales leaders at SaaS companies." The agent picks the right engine and returns structured data.

4. Real-time data > pre-built lists. This was a non-negotiable from day one. Pre-built lists go stale. Searching 300M+ profiles in real time costs more to run, but the data quality difference is night and day.

What I'd do differently

  • I underestimated how much the community matters. I spent too long on product and not enough on building in public. I should have been sharing the journey from week one β€” the architecture decisions, the pricing experiments, the first user feedback. That's something I'm fixing now.

  • Pricing took 3 iterations. I started too cheap, then too expensive, then found the sweet spot: $10 for 100 credits (trying it out) up to $150 for 2,500 credits (power users). Free credits on signup, no card required.

Where it is now

Live at trysalestack.com. Works as an MCP server (mcp add salestack https://trysalestack.com/mcp) for Claude Code / Codex, or via REST API for Clay and custom pipelines.

Free credits included on signup β€” no card needed.

Question for you

If you're building AI agent workflows (or thinking about it), what's the hardest part of plugging real-world data into your agent? Is it finding the data, structuring it, paying for it, or something else entirely?

I'd genuinely love to hear where the friction is, it'll shape what I build next.

Dave

posted toAvatar for product Parallel AI
Parallel AI