--- title: "GTM engineering" description: "Ayush Rai on GTM engineering: a live revenue-role job product, public-source data pipelines with provenance, an explainable scoring demo with a human approval gate, and an honest map of what is built, what is being studied, and what comes next." canonical: "https://www.ayushrai.site/gtm/" last-updated: "2026-10-18" --- # GTM engineering Source: https://www.ayushrai.site/gtm/ Markdown: https://www.ayushrai.site/gtm.md Ayush Rai on GTM engineering: a live revenue-role job product, public-source data pipelines with provenance, an explainable scoring demo with a human approval gate, and an honest map of what is built, what is being studied, and what comes next. I build data and decision systems for revenue work: job-market data pipelines, entity resolution, explainable scoring, and human-approval workflows. From April 2024 to August 2025 I worked as an AI engineer at FoCDoT Technologies, on AI engineering and technical evaluation. Since then I have built my own products and done contract evaluation work for frontier-lab programs. I am now studying GTM engineering on top of that background, and this page separates what I have built from what I am still learning. ## Walkthrough video Not recorded yet. It will cover: - RevenueRoles: one posting from source to published listing. - Revenue Intelligence Engine: an ICP run, the score breakdown, and the approval queue. - Where each project sits in the data, orchestration, execution, and agent layers. ## How to read the evidence - Live: A public URL serves it today. - Runs locally: Code and tests are in a public repository; there is no hosted deployment. - Synthetic demo: The workflow runs end to end on fictional data with mock enrichment. ## Product and projects ### RevenueRoles (product, Live) Job discovery for technical revenue roles such as GTM engineer, RevOps engineer, and forward deployed engineer, classified by the work a posting describes rather than by its title. Stack: Next.js, FastAPI, Supabase Postgres, pgvector, Inngest, Vercel Live: https://revenueroles.in · GitHub: https://github.com/ayushrai-hub/RevenueRoles · On this site: /products/revenueroles What it shows: - Data layer: ingestion from four job sources into one schema. - Entity resolution: deduplicating the same posting across sources. - Classification by the work described, not the title. - Signal freshness: scheduled re-discovery through Inngest. Limits: - Listing freshness and salary extraction still need checks (units, ranges). - Several signed-in features are not verified in production. - No user or revenue numbers exist yet. ### Revenue Intelligence Engine (project, Synthetic demo) Synthetic-data GTM pipeline that scores 42 fictional companies against an ICP on a deterministic 100-point rubric, researches the top accounts, and holds export behind human approval. No real leads, CRM writes, or outbound. Stack: Python, FastAPI, SQLAlchemy, Next.js, pytest Live: https://cashmaker-two.vercel.app · GitHub: https://github.com/ayushrai-hub/REVENUE-INTELLIGENCE-ENGINE · On this site: /projects#revenue-intelligence-engine What it shows: - ICP-driven account scoring on a transparent 100-point rubric. The score is never produced by an LLM. - Buying-signal detection: hiring, funding, expansion, product launch, technology adoption. - LLM account research at temperature 0 with labeled claims, and a deterministic fallback when no key is set. - A human approval gate between research and any CRM-ready export. - Run IDs, stage logs, and idempotent upserts on re-runs. Limits: - All companies, contacts, and signals are fictional, and enrichment is a mock provider. - No Clay, Apollo, or CRM integration. No outbound, real leads, users, or revenue. ### Relationship Intelligence Engine (project, Runs locally) TypeScript CLI and local dashboard that finds technical founders and companies hiring AI/ML engineers from public sources, keeping source, URL, time, and a verification status on every important field. Stack: TypeScript, Node.js, PGlite, PostgreSQL, Playwright GitHub: https://github.com/ayushrai-hub/SYSTEM-job · On this site: /projects#relationship-intelligence-engine What it shows: - Account and people discovery from public sources: the YC directory, GitHub signals, accelerator portfolios. - A staged pipeline: discovery, normalization, entity resolution, enrichment, verification, signal detection, scoring, deduplication, export, refresh. - Provenance on every important field (value, source, URL, time, confidence) and an explicit status: verified, inferred, unverified, conflicting, or missing. Unknown values stay empty. Limits: - A personal research tool, not a lead factory. - No paid enrichment vendors are wired in. - Audit figures in the repository are its own notes and have not been re-run. ### SpiderWeb (project, Runs locally) Turns your own LinkedIn data export into a searchable map of your network: people, companies, roles, and conversations, deduplicated, with a graph view. Runs locally; no production deployment. Stack: TypeScript, Next.js, PostgreSQL, Redis, Docker GitHub: https://github.com/ayushrai-hub/SpiderWeb · On this site: /projects#spiderweb What it shows: - Two-stage file detection (filename, then column signature) for messy exports. - Person and company resolution with per-file import, update, dedup, and reject counts. - Rule-based relationship signals that state why each person surfaced. Limits: - Works only on your own LinkedIn export. No production deployment. ### MailU (project, Runs locally) Local email intelligence tool: Gmail API sync, zero-shot categorization, semantic search, and RAG chat over your own mail on a local model. Stack: Python, FastAPI, ChromaDB, Ollama, Gmail API GitHub: https://github.com/ayushrai-hub/MailU · On this site: /projects#mailu What it shows: - Email data handling: Gmail API sync, parsing, and storage. - Zero-shot categorization, semantic search, and RAG chat on a local model. Limits: - A local tool for one mailbox. The repository's test summary has not been re-run. ## GTM infrastructure layers: built and missing ### Data Discover, collect, enrich, validate, and organize company, contact, and signal records. Built: - RevenueRoles ingestion, normalization, and deduplication across Greenhouse, Lever, Ashby, and RemoteOK. - Field-level provenance and verification status in the Relationship Intelligence Engine. - Person and company resolution in SpiderWeb. Gap: No paid enrichment provider (Apollo, Clay) is wired into any project. ### Orchestration Coordinate workflows, apply business rules, manage dependencies, and decide what happens next. Built: - Inngest scheduled discovery in RevenueRoles. - A staged pipeline with run IDs and idempotent upserts in the Revenue Intelligence Engine. - An optional Redis-backed ingestion worker in SpiderWeb. Gap: No CRM-triggered or webhook-driven workflows yet. ### Execution Update CRM records, create tasks, trigger approved outreach, notify reps. Built: - CSV, JSON, and XLSX exports, gated by an approval queue in the Revenue Intelligence Engine. Gap: No CRM writes, no outbound sending, and no deliverability work. ### Agents Use LLMs and tools for contextual research, unstructured data, and bounded decisions. Built: - LLM account research with labeled claims and a deterministic fallback. - RAG over a mailbox in MailU. - Evaluation discipline from contract evaluation work: judging model output against criteria. Gap: No production agent with measured outcomes. ### Revenue operations ICP definition, qualification, pipeline metrics, and the people who use the system. Built: - ICP definition, explainable scoring, and an approval gate, all in a synthetic demo. Gap: No HubSpot or Salesforce work shown, and no pipeline metrics from real use. ## What I already know ### Languages and frameworks - **Python** (In public code): FastAPI services, pipelines, and pytest suites (Revenue Intelligence Engine, MailU, the RevenueRoles worker). - **TypeScript** (In public code): Next.js apps, CLIs, and pipelines (RevenueRoles, Relationship Intelligence Engine, SpiderWeb, this site). - **Next.js and React** (In public code): The RevenueRoles web app and the Revenue Intelligence Engine console. - **FastAPI** (In public code): The Revenue Intelligence Engine API and the RevenueRoles classification worker. ### Data - **PostgreSQL and SQL** (In public code): Supabase with pgvector and row-level security in RevenueRoles. PGlite or Postgres in the Relationship Intelligence Engine. - **SQLAlchemy** (In public code): Persistence for the Revenue Intelligence Engine, SQLite locally with Postgres-compatible models. - **Vector stores** (In public code): pgvector in RevenueRoles, ChromaDB in MailU. - **Entity resolution and deduplication** (In public code): Across job sources, public company data, and LinkedIn exports. ### Orchestration and automation - **Inngest** (In public code): Scheduled discovery jobs in RevenueRoles. - **Queues and workers** (In public code): Redis-backed ingestion worker in SpiderWeb; a resume queue in RevenueRoles. - **n8n, Make, Zapier** (Used, no public project): Familiar with the platforms. No public project uses them yet. ### AI - **Structured LLM output** (In public code): JSON account research with required-field checks and a deterministic fallback in the Revenue Intelligence Engine. - **Tool calling and agent loops** (Used, no public project): Understood and used in experiments. No public project of mine shows it yet. - **RAG and embeddings** (In public code): MailU on a local model through Ollama. - **LLM evaluation** (Used, no public project): Contract evaluation work for frontier-lab programs: reviewing model output against criteria. Task materials are not public. ### GTM platforms - **Apollo.io** (Used, no public project): Used as a product. Its API is not integrated in any project yet. - **Clay** (Studying now): Waterfalls, HTTP API columns, and where Clay ends and a backend begins. - **HubSpot** (Studying now): CRM object model, associations, and safe create-or-update through the API. ### Testing and delivery - **pytest, Vitest, Playwright** (In public code): Test suites across the projects on this page. - **Vercel, Netlify, Docker** (In public code): RevenueRoles and the Revenue Intelligence Engine on Vercel; this site on Netlify; Docker Compose for local Postgres and Redis. ### Practices - **Provenance and verification status per field** (In public code): Relationship Intelligence Engine. - **Explainable, deterministic scoring** (In public code): Revenue Intelligence Engine. - **Human approval gates before export** (In public code): Revenue Intelligence Engine. - **Rate-limited collection from public sources** (In public code): Relationship Intelligence Engine. ## What I am studying now I am studying how B2B companies build and run revenue systems: how they find accounts, enrich and verify records, read buying signals, qualify leads, orchestrate workflows, sync with a CRM, and use agents with a human in the loop. I read documentation, trace real API requests and responses, and build against them, rather than watching tool tours. ### Clay - How does a data waterfall choose providers, handle missing values, and control enrichment cost? - Which steps belong in Clay, which in a custom backend, which in the CRM, and which need a human? - How do HTTP API columns connect Clay to my own services? ### Apollo API - What is the difference between finding a person, enriching a record, and verifying it? - How do credits and rate limits shape batching, retries, and pipeline design? ### HubSpot CRM API - How do contacts, companies, and deals relate through associations? - How do unique identifiers and create-or-update calls prevent duplicate records? - How should sync conflicts between an enrichment source and the system of record be resolved? ### Workflow orchestration - When are n8n, Make, or Zapier enough for production, and when is a queue, database, and event-driven backend the better choice? - How do triggers, webhooks, retries, idempotency, and human approval steps fit together reliably? ### Commercial metrics - How are pipeline generated, enrichment coverage, reply rate, meetings booked, and cost per qualified lead measured? - How do you decide whether an automation is worth building? ### Compliance and deliverability - What do CAN-SPAM and Google's sender guidelines require: authentication, unsubscribe handling, and spam-rate limits? - How should consent, suppression lists, and sender reputation shape an outbound system? ## Resources I am using 1 of 11 read. Mostly vendor documentation. Customer results in vendor blogs are vendor-reported, not audited. ### How GTM engineering teams work - [Clay: the building blocks of a GTM engineering system](https://www.clay.com/blog/gtm-infrastructure) (read 2026-10-18): The four layers: data, orchestration, execution, agents. - [Clay: how we built a GTM engineering function](https://www.clay.com/blog/how-we-built-gtm-engineering-function) ### Clay mechanics - [Clay University documentation](https://university.clay.com/docs) - [Clay: waterfalls](https://university.clay.com/docs/building-a-data-waterfall) - [Clay: HTTP API integration](https://university.clay.com/docs/http-api-integration-overview) ### Data providers and CRM - [Apollo developer docs](https://docs.apollo.io/) - [Apollo: people enrichment](https://docs.apollo.io/reference/people-enrichment) - [Apollo: rate limits](https://docs.apollo.io/reference/rate-limits) - [HubSpot API reference overview](https://developers.hubspot.com/docs/api-reference/latest/overview) ### Compliance - [FTC: CAN-SPAM Act compliance guide for business](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) - [Google: email sender guidelines](https://support.google.com/mail/answer/81126) ## What I will build next - Add a real Apollo enrichment provider to the Revenue Intelligence Engine behind its existing provider interface, with rate-limit handling and credit accounting. Synthetic mode stays the default. - Push approved accounts to a HubSpot developer sandbox as companies and contacts with associations, keyed on domain so re-runs update instead of duplicating. - Call the scoring API from a Clay table through an HTTP API column, and compare enrichment coverage and cost per provider in a small waterfall. - Write an architecture note for each flagship: why it is designed this way, what failed, what it costs to run, and how I know it works. - Build an autonomous personal agentic system for GTM operations. Agents run routine research, enrichment, scoring, and follow-up preparation on their own, and a person approves anything that leaves the system. It improves over time from logged outcomes, new data, and evaluation evidence. Design goal: run at a fraction of the cost of sending every step to a hosted frontier model, by routing routine steps to smaller or local models and measuring cost per task. Not started. - Record the Loom walkthrough and embed it on this page. _Unverified award metrics are omitted. Wording matches the public site._