Back to Hub
Go-To-Market SystemsCase Study 04In progress

One System for Every Growth Channel, Built to Prove Which One Pays

OutboundInboundNurtureABMRetentionReferral

Six engine types the shared spine is designed to run.

Executive Summary

Most growth teams run each channel on its own island. Outbound sits in one tool, inbound in another, nurture and referrals somewhere else again, and every island keeps its own contact list and its own scoreboard. The same prospect gets touched more than once, and when a deal finally closes, nobody can say for certain which motion earned it, so budget flows to whichever channel argues loudest instead of the one that actually pays.

GTM-System is a single go-to-market platform built to fix that at the foundation. Its shared spine is built and verified, and six engine types are designed to plug into it instead of each one getting rebuilt from scratch. The spine keeps history as an append-only ledger and stamps attribution at write time, so which engine and play produced a given dollar is answerable by construction rather than reconstructed with a fragile join long after the fact. It is a work in progress, and the design goal is simple: a platform that can always answer the question that decides the budget, which is which engine actually made the money.

The Problem: Six Tools, No Honest Scoreboard

  • Channels that don't talk

    Each motion lives in its own app with its own list, so one prospect gets hit by three of them and the data never agrees with itself.

  • No way to prove what worked

    When revenue lands, there is no reliable path back to the motion that caused it, so spend gets set by gut and by whoever lobbies hardest.

  • Compliance on a sticky note

    Consent and do-not-contact rules live in a spreadsheet or someone's memory, and a single wrong send is a legal and deliverability problem.

The Design: One Foundation, Built for an Honest Answer

  • One shared spine

    Every engine is designed to read and write the same contact record and the same history, so there is no double-touching and no version of the numbers that disagrees with another.

  • The receipt is stamped at the sale

    Attribution is written into the record at write time, because that link cannot be rebuilt later. That is what makes which channel pays answerable at all.

  • Permission lives in the code

    One gate stands in front of every send path, and every decision it makes is logged. Consent is a legal question signed off per client, never an inherited default.

How It Works: One Loop, Every Engine

The six engines are not six separate systems. They are designed as one runner reading different config, so every engine follows the same four steps. Hover any principle below to see the design behind it.

Trigger
Something worth acting on happens and the platform picks it up as a signal.
Permission
One gate decides whether this contact can be reached right now, before anything goes out.
The right move
The platform selects the play that fits this engine and this moment.
The ledger: stamped by construction

One spine, six engine types

Add or turn on an engine without rebuilding your data or your reporting. Every engine is designed to share one contact record, one history, and one set of rules.

Configure, don't rebuild

A new client deployment is a configuration job across five surfaces, not a fresh multi-week build. The core stays a single codebase.

The receipt is stamped at the sale

Attribution is written into the record at the moment of the touch and the moment of the sale, so revenue traces to the engine and play that earned it instead of a guess after the quarter closes.

Permission lives in the code

One coded gate stands in front of every send path. If a contact should not be reached, for consent or suppression or because another engine already has them, it is blocked and the reason is logged.

A history that only adds

The record is append-only. Nothing is edited or deleted, so any source can be audited and back-tested, and the numbers can never be quietly rewritten.

Enrichment that spends last

Per field, the platform checks its cache, then free sources, and only pays a vendor for what is still missing. It stops on the first hit.

One spine, six engine types

OutboundInboundNurtureABMRetentionReferral

The Evolution of a Single Engine

This platform is the next step beyond a single AI outbound engine (Case Study 01). That engine proved the pattern on one channel. GTM-System generalizes it into reusable, multi-tenant infrastructure that six engine types are designed to share, so the pattern is not rebuilt once per channel or once per client.

Under the hood it is TypeScript on Supabase Postgres, with the task layer written on the Trigger.dev v4 SDK and the whole platform built with Claude Code under a plan-reviewed workflow. Cross-tenant isolation, the append-only guarantees, and the compliance gate are enforced in the database and the code rather than left to convention.