How I Built a GTM Cockpit on Headless Connectors (MCP + API)

The headless GTM argument is that you should own the head - the interface where you see, decide, and steer - and rent the bodies underneath. That is easy to say. This is how I actually did it: a build log of the cockpit I assembled on top of headless connectors instead of renting a platform, what is wired into what, and the parts that bit me. I am not going to pretend my stack is special or the only way. The point is the shape - one head I own, many bodies I rent, joined by API and MCP - because that shape is now buildable by any technical operator in a weekend, and it is the thing the vendors did not price in when they went headless.

The architecture, in one sentence

A single self-hosted app is the head. Every data source, sending channel, and record store underneath it is a headless connector it calls. The app holds no proprietary data engine of its own - it is a cockpit, not a database company. It reads from and writes to rented services over their APIs and, increasingly, their MCP servers, and it presents one screen where a human runs the whole motion. Swap any connector and the head does not change. Change the head and the connectors do not care. That decoupling is the entire benefit.

The bodies (what I rent)

Concretely, the connectors my cockpit calls: Data: Apollo for contact and company data, over its API. A commodity I pay for by the credit; I would rather buy it directly than through a platform markup, and I can swap it without touching the head. Sending: Amazon SES or a Google Workspace mailbox, switchable per domain. The cockpit talks to SES over the AWS SDK and to Gmail over an app password; the head does not care which is active. Replies: IMAP, read straight from the active mailbox and parsed in the app. When a known lead replies, the cockpit stops their sequence and drafts a response for me to approve. Records: HubSpot as the CRM of record, synced over its API. The cockpit is where I work; HubSpot is where the data is canonical. Everything else: Google Search Console and GA4 via a service account, Stripe for payments, and the model APIs (Claude, plus OpenAI for one connector) for research and drafting. Each is a rented, swappable, agent-callable body. A deliberate choice: the clients for these are thin, direct-fetch wrappers, not heavyweight SDKs. The surface I use from each is small, the APIs shift, and I want changes localized to one file. Owning the head means owning these seams on purpose.

The head (what I own)

The head is GTM OS: Node, SQLite, plain HTML and JavaScript, no build step, written and maintained with Claude Code. It gives me one operator surface for the whole motion - outbound, replies, demand signals, lifecycle from trial to paid, deliverability health - and a hard rule that a human approves anything that leaves the building. Every draft is shown to me byte for byte before it sends. It runs on Fly.io for a few dollars a month. The database is one file on a disk I control; the leads, replies, and keys never leave my infrastructure. None of that is impressive engineering - it is deliberately boring engineering. The value is not the tech; it is that the interface is mine, and so are the decisions encoded in it.

Why build the head instead of buying a platform

Three reasons, the same ones I lay out in rent vs own your GTM stack, aimed at the interface. Control: the views my operators see are the ones I decided they should see, not the ones a vendor's roadmap landed on this quarter. Marginal cost: the cockpit pays for compute and data, not a per-seat platform margin, so the cost curve flattens as the motion scales. Optionality: because every connector is headless and swappable, I am never locked in. A better sender, a cheaper data source, a new agent - all of them plug in under the same head.

What broke, and what is genuinely hard

Owning the head is not free, and the honest part is the useful part. Amazon SES starts in a sandbox that only emails verified addresses and caps you at 200 a day until you request production access - useless for cold outreach on day one. I bridged on a Google Workspace mailbox while approval cleared. Plan for it. Rented APIs fail in ways a polished platform hides from you: rate limits, partial responses, the occasional silent failure where a call "succeeds" and returns nothing useful. When you own the head, those are yours to detect and handle - the cockpit needs the gates and retries the vendor UI used to provide invisibly. And the big one: you become the vendor. Deliverability questions at 11 p.m. are yours. Maintenance is yours. The connector that changes its API on a Tuesday is your problem. None of it is hard in isolation; all of it is now your job. That is the real price of owning the head, and you should pay it with your eyes open.

Should you build your own head?

The same test as the hub: if you or someone on the team is comfortable in a codebase, and the cockpit is where your competitive edge lives, build it - the build is cheap now and the control compounds. If you are non-technical or need the motion running this quarter, rent the head deliberately and architect so you can own it later, keeping your data in connectors you can call yourself. There is no wrong answer, only an unconscious one: letting a vendor own your head by default because you never decided. If you want the skills that build this kind of thing without standing up a whole app, the Operator Playbook is the set of GTM Claude skills I use - the cold-outbound-sequence skill wrote the sequences inside this cockpit. If you want the built system, GTM OS is it.