Tech stack ownership

# Tech stack ownership

## Goal

Specify the minimum GTM technology system the current motion actually needs: what records exist, what each tool is for, how they connect, who owns them, and what not to buy yet.

The stack exists to make ICP qualification, pipeline evidence, campaigns, onboarding, and metrics visible. It does not exist to look like a larger company.

This is architecture for commercial operations. Do not buy software, connect production systems, or move customer data to a new vendor. Do not invent a stack the motion cannot staff.

Complete the analysis autonomously. Do not stop to ask clarifying questions.

Do not modify application code.

## Prerequisites

Read the latest ICP, campaign, nurture, pipeline, deals, onboarding, retention, and metrics files if present; existing CRM, email, billing, support, and analytics tools named in the repository; access, admin, and cost notes; and any existing `docs/gtm/stack.md`, `docs/gtm/stack.yaml`, and `docs/gtm/stack-changelog.md`.

If the motion is still founder-led with a handful of accounts, prefer a boring system of record plus honest spreadsheets over a five-tool automation mesh.

## Evidence standard

Use the shared GTM labels.

A vendor’s marketing site does not prove the company needs the product. An unused seat is evidence against the tool. A founder inbox is a system of record whether or not anyone likes that.

## Step 1: Inventory what is already true

List every tool, inbox, spreadsheet, and board that currently stores:

* accounts and people
* conversations
* opportunities
* offers and invoices
* usage or activation
* support
* campaign activity

For each: owner, cost, object it stores, whether it is source of truth, failure mode, and whether anyone actually uses it.

Name the real source of truth per object even if it is messy.

## Step 2: Define the objects and handoffs

Specify the canonical objects: purchasing unit, contact, conversation, opportunity, offer, customer, ticket, experiment.

For each object: required fields from the GTM prompts already written, system of record, systems allowed to copy it, and the handoff that moves it (marketing → sales → onboarding → success).

If two tools both think they own the opportunity, pick one. Dual CRMs are not a strategy.

## Step 3: Choose the minimum stack

For the current stage, select the smallest set that can:

* qualify against ICP gates
* keep one pipeline
* send or track the planned sequences without shadow lists
* record activation and support
* produce the metric definitions without heroic export archaeology

Default bias: one CRM-ish system of record, billing as the money source of truth, product analytics for activation, support where the tickets already live.

Reject:

* tools whose only job is dashboards of invented data
* automation that writes fake personalization
* enrichment that guesses emails or scraped personal data
* a second outreach tool because the first one was never configured
* enterprise suites for a ten-account motion

For every rejected category, say what would have to be true before revisiting it.

## Step 4: Configuration rules, not a vendor tutorial

Write the operating rules:

* field list mapped to pipeline gates and deal fields
* stage definitions
* who can create, edit, and close
* what is automated versus manual
* backup and export
* what data is too sensitive to put in the tool
* review cadence

Do not paste a vendor onboarding guide. Write the company’s rules.

## Step 5: Cost and capacity

Fully loaded monthly cost, including founder admin time. If admin time exceeds selling or onboarding time, the stack is too large.

## Step 6: Desk-test

1. Each object has one source of truth.
2. Required fields match the pipeline and deal plays.
3. No tool is required for a motion that does not exist yet.
4. No recommendation requires unauthorized data or scraped personal contacts.
5. A new hire can tell where to write a lost deal.

## Decision

* `INSTALL`: the named minimum stack and rules may be configured
* `INSTALL NARROWLY`: system of record plus billing only
* `HOLD`
* `SIMPLIFY`: current tools exceed the motion; name what to turn off

Lead with:

“As of [date], the GTM system of record is [tool or board] for [objects], with [N] additional tools, fully loaded cost [amount or unknown], decision [INSTALL / INSTALL NARROWLY / HOLD / SIMPLIFY].”

## Deliverables

### 1. `docs/gtm/stack.md`

Inventory, objects, minimum stack, rejected tools, configuration rules, cost, desk tests.

### 2. `docs/gtm/stack.yaml`

`version`, `status`, `decision`, `systems_of_record`, `tools`, `rejected`, `objects`, `handoffs`, `fields`, `cost`, `assumptions`, `unknowns`, `sources`.

### 3. `docs/gtm/stack-changelog.md`

Append only.

## Boundaries

* Do not purchase, connect, or migrate live data.
* Do not recommend scraping, enrichment of private contacts, or secret access.
* Do not design for a 50-person GTM team the company does not have.
* Do not automate a process that has no evidence.
* Do not create a second source of truth “for now.”
* Preserve uncertainty.

## Done when

* Sources of truth, minimum tools, and refusals are explicit.
* Fields map to existing GTM plays.
* Desk tests passed or forced `SIMPLIFY` or `HOLD`.
* The three files agree.