systemix docs

For marketers

How Systemix works for marketers — experiments as files, PostHog evidence pulled for you, a ledger of what converts.

What Systemix does for you

Every landing variant, CTA test, and funnel bet becomes one readable file: the hypothesis, the ICP it targets, the variants, the metric, and the live PostHog evidence — all in experiments/<id>.mdx. No dashboard sprawl; the current state of any bet is one page (see a live one).

The evidence comes to you: a daily runner pulls PostHog numbers, evaluates them against thresholds, and queues a close proposal when a call is ready. When you close, the learning is appended to LEARNINGS.md with a confidence and a citation — a compounding ledger of what actually converts, so you never rerun a dead test.

Your 10-minute start

  1. Frame the bet. /init-experiment <id> asks for ICP · JTBD · hypothesis · metric and writes the file. Keep the hypothesis falsifiable — "X converts better than Y for Z" beats "improve the landing".
  2. Write the variants. /write-variants proposes copy calibrated to the ICP in the file — you approve what ships.
  3. Wire the metric. /measure maps the metric to a PostHog event (/connect-signal first if PostHog isn't wired). Conversions are tagged with the variant automatically.
  4. Let it run. The daily runner advances the experiment; you'll get a close-proposal card when the evidence is decision-ready.

Your weekly loop

  • Run /growth-audit — a prioritized brief over all running experiments: what's decision-ready, what's stalled, what to kill.
  • Close what's ready (/close-experiment) — the decision and learning are written back automatically.
  • Skim the memory feed before framing the next bet: the ledger is your best prior.

Where next

On this page