Overview
Turn customer behavior into versioned, testable, and explainable state.
Kite is an event-driven Customer Success as Code engine. It turns product events into customer state using definitions that live in your repository, not settings hidden in a dashboard.
Define activation, lifecycle progression, customer health, churn risk, and meaningful signals in TypeScript. Kite evaluates those definitions as events arrive and explains the resulting state changes.
Active development
Kite is under active development. The CLI, Node.js SDK, and configuration DSL are available
from npm. We recommend starting in the isolated test environment.
Why Kite?
Customer-success logic is product logic. It deserves the same discipline as the application that produces it:
- Explicit: activation and risk are defined as concrete, readable conditions.
- Versioned: every change is visible in Git and can be reviewed before release.
- Testable: events can be processed locally without touching production data.
- Deterministic: the same configuration and event history produce the same state.
- Explainable: teams can inspect what changed and which event caused it.
This replaces ambiguous rules such as “the customer seems inactive” with definitions your product, data, and Customer Success teams can discuss and verify together.
How it works
Kite connects three working layers:
| Layer | Responsibility | Example |
|---|---|---|
| Config | Defines lifecycle, journeys, rules, segments, health, and signals. | Activation requires three feature.used events in seven days. |
| Events | Records product activity for a stable customer ID. | account.created, feature.used, subscription.upgraded |
| State engine | Computes current customer state from config and event history. | Customer becomes activated and health increases to 82. |
The flow is intentionally simple:
your product -> events -> Kite state engine -> customer state and signals
^
|
versioned TypeScriptEvents describe what happened. Configuration defines what it means. Kite computes what is true now.
A Kite project
kite init creates a functional project rather than an empty scaffold:
kite.config.ts
states/lifecycle.ts
journeys/onboarding.ts
rules/activation.ts
segments/at-risk.ts
health/overall.ts
signals/engagement.ts
.kite/config.jsonThe generated project already models an onboarding journey, lifecycle transitions, an at-risk segment, and an event-based health score. Run it as-is first; then adapt each definition to your product.
The development loop 🔁
Treat Kite configuration exactly like application code:
edit -> validate -> test locally -> inspect state -> review diff -> deploykite validate
kite devkite validate catches invalid references and incompatible definitions before deployment.
kite dev provides a fast local event-to-state loop at http://127.0.0.1:4401 and logs the
state changes produced by each event. Deploy to test only when the behavior is correct, then
promote deliberately to live.
Keep environments separate 🔐
Test keys start with kt_test_ and live keys start with kt_live_. Never expose either key
in browser code, commit it to Git, or include it in logs.
Choose your next step
- I want to see Kite work: follow the 5-minute quickstart.
- I need package and runtime details: read Installation.
- I want to understand the model first: explore Concepts.
- I am ready to model my product: continue to the Config Reference.
Start with one customer outcome and the smallest reliable set of events. A precise activation definition is more valuable than a large, speculative event catalog.