AnyTeam — AI-Native Sales Operating System

An AI-native B2B sales intelligence platform built from inception to launch on a two-engineer backend team. I scaffolded the service-oriented architecture, built three of its subsystems, and authored two of its LLM pipelines.

Context

AnyTeam gives account executives real-time insights, stakeholder mapping, and meeting intelligence, integrating deeply with Google Workspace to sync calendars and contacts.

What I built

I scaffolded a domain-layered, service-oriented backend — Node.js, Express, PostgreSQL and RabbitMQ — deployed on GCP as two independently scaled Dockerized services: an API and an async worker.

Within it I owned three subsystems: a Google Calendar and Contacts sync engine for automated relationship mapping; a database-driven scheduler supporting dynamic per-user cron jobs across tenants; and a cross-platform notification system over FCM and APNs backed by a custom rule engine.

AnyTeam architecture: web and macOS clients call an Express core API, which publishes to a durable AMQP exchange; a Node.js worker service consumes meeting, transcript, research and notification queues and talks to PostgreSQL, Google APIs, LLM APIs and a notification rule engine that pushes through FCM and APNs. — System architecture — API and worker as two independently scaled services

Sequence diagram of the Google Calendar sync: an initial sync split into 13 monthly chunks processed in parallel through the queue, webhook channel registration, then incremental sync driven by push events and nextSyncToken. — Calendar sync — chunked initial sync, then push-driven incremental sync

Global scheduler: a one-minute Cloud Scheduler tick triggers a dispatcher that claims due rows with FOR UPDATE SKIP LOCKED, marks them queued and publishes them to per-type queues; workers run the job, compute the next run time and set the row back to pending. — Global scheduler — one tick, a jobs table and per-type queues

How the scheduler works, in detail: One cron job instead of thousands →

Notification rule engine: a system event checks settings and permissions, then Do Not Disturb, then looks up active device tokens and sends through FCM for web and APNs for macOS, recording status and pruning expired tokens. — Notification rule engine — settings, then Do Not Disturb, then device tokens

LLM pipelines

Two queue-driven worker pipelines. Meeting intelligence maps attendees to buyer accounts by email domain with an idempotent get-or-create upsert, then exports each transcript from Google Drive to cloud storage and summarises it with GPT-4o so account executives never read a raw transcript. Account research runs as enqueued jobs that combine Perplexity Sonar news search with GPT-4o synthesis, version-tracked behind a per-account research-status gate.

Observability

I added structured logging with trace-context propagation and centralized error forwarding, giving cross-system visibility. This is the first project in my work where observability was designed in rather than retrofitted.

Outcome

Launched November 2025 after eleven months, serving hundreds of tenants.