A CEO’s Guide to GTM: What used to cost millions, now costs $30

Six weeks ago, I built a custom sequence analytics reporting interface I could deploy to anybody at our company in about 30 minutes, for about $30 in token costs.

I was reflecting on what this used to cost when I was running sales and GTM Ops teams. I’d have to hire a RevOps analyst and data engineer to hack together a curated set of reportable tables by connecting the CRM, the sequencing software, and our data warehouse just to get the data right. We'd also have to hook it up to a data viz tool like Tableau online, and then get the final output I wanted, an accurate reporting interface.

That meant hiring the right team, buying a ton of software, getting data plumbed correctly, and having a data hosting solution. An expensive team, expensive software, time, and prioritizing. I won’t even get into maintenance costs. 

That's just one example of how things have changed. And it's the reason I’m passionate about making Apollo's developer surface a first-class product. 

Here's how it works, and why I think the builders who get this right are the ones who'll be operating at a different scale than everyone else.

My $30 moment didn't come out of nowhere

The popular frame for AI in GTM is "AI makes your workflow faster." That’s true, but it misses the structural point.

Every historically sophisticated revenue team runs approximately the same stack. There are multiple systems of record, tools that were procured through different company eras, data challenges, and so on.

What do businesses really want? Insights, valuable information, and guidance about what’s working and what isn’t. Businesses want to grow and get better, but this setup gets in the way.

First, core systems are purchased. Hubspot, Marketo, Salesforce, Sequencing, Dialing, Quoting, to name a few. They all have different data models and house different data types. 

Enter your analytics team. They pull all of the data from these core systems, procure a data warehouse, and land the data there. Build out your ETL layer to ensure you have standardized reportable tables. Standardized reporting gets produced based on that layer. Finally, ad-hoc requests begin to pour in because the foundation to get answers accurately and quickly actually exists.

Building this is expensive, driven primarily by recruiting and hiring people with the expertise and software cost.

What's changed is where intelligence enters that stack. Now that infrastructure already exists inside Apollo. When I built that dashboard, I didn't set up a data warehouse or wire up ETL pipelines. I just told Apollo what I wanted and got it in 30 minutes. No system pain, no big team, no alignment meetings on definitions. A stable data model that worked out of the gate giving me what I needed.

This is possible because Apollo already has the plumbing: data, intelligence, and execution in one place, and our new developer surface is how any agent or workflow taps directly into it.

Breaking down Apollo’s developer surface

Today, we're giving this new developer surface a real home at apollo.io/developers. It ships with three ways to build on Apollo, what we call Headless GTM:

The API is the foundation. It's always been there, but we've made it far easier to build against. We published a public OpenAPI spec that's machine-readable and CI-synced. Based on our initial analysis, agents are now completing multi-step tasks with up to 47% fewer tokens than from web docs. Hand it to Claude Code and it can write the integration for you. We also published an llms.txt index, so every endpoint is directly consumable by AI coding agents.

The CLI is for production workflows. Headless, scheduled, agentic. No UI, no session state. When I built that sequence analytics dashboard, I was effectively deploying company-wide infrastructure. What did I use? CLI. Once you've got a workflow you trust, this is how you deploy it to run on its own.

And the MCP now comes in two forms:

1. Native integrations: We already have Apollo live in Claude, Codex, and Perplexity. Today we're adding Cursor, Replit, GitHub Copilot, and n8n. Apollo shows up directly in the marketplace of each, where developers are already building. Nothing to configure.

2. Standalone MCP: If you're working in a tool we don't have a native listing for yet, you're not blocked. Point to https://mcp.apollo.io/mcp from any MCP-compatible client and you're connected to Apollo's full data surface, no formal integration required.

All three plug into the same data, intelligence, and execution loop. But what determines how far you can take any of them comes down to one thing: context.

Why context is the whole game

Boris Cherny, who created Claude Code at Anthropic, posted a framework in late June that got 3M+ views. 

He mapped out 5 archetypes for how roles are evolving on AI-powered teams: prototyper, builder, sweeper, grower, maintainer. His take was that these archetypes are cutting across traditional job functions. For example, an engineer, a designer, and a PM might all fit the same archetype depending on how they work.

I think he's right. And the reason those archetypes are blurring is that AI rewards context over credentials. The model and the prompt matter less than what you're feeding in. The people who move fastest are the ones who show up with the best context. Why did the sequence reporting layer get built so quickly? I knew what I was looking to build and was able to generate it in half an hour. I had context on the output I wanted, I just needed the right inputs; Apollo has them all.

For GTM, that foundational “input” context is contacts, companies, signals, outbound history, and analytics. The full picture of your market and what you've tried. Every email where you earned a positive reply, every proposal a customer passed on... that's what Apollo's developer surface makes programmable. Every workflow you run informs the next one and the system gets smarter with every new action.

The interesting question is who's consuming that context: builders or agents. For most, it's both. Our builders are composing workflows in Claude Code or Cursor and getting the "$30 and 30 minutes" version of something that used to require a team. Then we also have agents running "next best action" loops that score, prioritize, and surface the right actions for our reps. Both work because the context is already there.

As those workflows get more sophisticated, the quality of GTM context they're operating with is what separates a good one from a generic one. That's the Apollo bet.

The builders who figure out how to give their AI the right GTM context, with the execution layer to act on it and a system that learns from every action, are the ones who'll be operating at a different scale than everyone else in two years. That is the new standard for "world-class GTM."

We're experiencing record revenue growth and got there by doing this, not just talking about it.

What we hope you build

Apollo has always been where GTM gets done. Now it's also where it gets built.

Visit apollo.io/developers, get an API key, and run one workflow before you close the tab… then let me know what you build with it.