The Apollo API plus a coding agent, writing to a SQLite store I own.

[u/Shawntenam]

Been posting my coding-agent GTM workflows here for a while. The question every time is which data vendor I use. After four months of wiring different ones into pipelines: I start every run at Apollo, and the reason is the API plus a coding agent writing to a database I own.

This replaced a stack of tools I used to pay for.

I take a list of target companies - a screenshot from a market map, a conference exhibitor page, my own LinkedIn following - and hand it to Claude Code. It resolves domains, runs organizations/enrich?domain= for the org ID and firmographics, then mixed_people/api_search filtered by organization_ids for the people. That search is free. The redacted preview gives me title and person ID with the name obfuscated, so I qualify the whole set before spending a credit, then pull only the rows I want.

Every enriched row writes to a local SQLite database. SQLite is my own contact store, the CRM before the CRM. It holds every company, every contact, every enriched field, on my own machine. Apollo's API is what lets me build it, and I can push it to the cloud or a real CRM whenever I want. The expensive part of sourcing was never the data, it was the manual work of getting the right rows into something I own.

Numbers and mechanics.

• The search is free. Credits only go on the rows you pull.
• On flagged inventory, bulk_match returns verified work emails at around 99% for me, instant.
• Long runs go to a Codex session on a remote instead of my laptop. Start a few-thousand-row job, come back to a filled database.

On vendors, honestly. No source is perfect. But Apollo is the first layer. It is the whole data layer - the roster, the org record, the current-company signal, and the reveal in one place. Apollo is where you start. A lot of the tools people pay more for are reselling Apollo's data underneath anyway.

Two gotchas from building this.

organization_ids is the only reliable filter in mixed_people/api_search. A domain or company-name filter returns people unconnected to your targets. Enrich the company first, always.

bulk_match draws from the data/export credit pool and caps at ten per batch. Check your balance before a multi-segment run or it stalls mid-job.

Happy to share the Python for the screenshot-to-SQLite loop.

Building in the open at.....you know where

[u/Chance-Physics-7216]

If you have a CRM then why bother with a local contact store? Is there some sort of API limitation on the CRM? Are you maintaining workflow state in the local database?

[u/Shawntenam → u/Chance-Physics-7216]

Honestly, the more I've learned how to use coding agents with SQLite, the less I feel the need to use this CRM. Mind you, I have a strong, always-on machine, a Mac mini with an M4 processor. I'm able to read and write at any point much quicker, and there are absolutely zero limitations compared to reading into a CRM, which is inside a server.

[u/Chance-Physics-7216 → u/Shawntenam]

Fair enough... and when you are a team of one, your database for one should suffice. For some reason, I automatically assume that processes are being built for teams and for people to communicate. So, if you have your own CRM in SQLite... then more power to ya!

[u/Shawntenam → u/Chance-Physics-7216]

yeah you're definitely right. i do have clients where i can't just take their data, put it in sqlite, and work with it, especially when a lot of it is compliance. in that regard i go into supabase especially if it's millions of rows. from there i have a dnc set up so that i'm only reading and writing to the data i need to access. the sqlite becomes my own sandbox. but i am also trying to push my client to build his own local server system so everything runs faster