CrowdRelay
Live · 14-day free trialFan growth for artists that runs itself, inside limits you set.
Most music tools give you a dashboard and leave the work to you. CrowdRelay keeps every fan an artist has met in one place, decides what is worth doing next, does it, and keeps a record of what changed. You approve each step, or let it run.
I built it for Virya first. The band is the first artist on it, so every feature meets real fans before anyone else uses it.
- lines of Rust
- ~100k
- crates with strict layering
- 6
- fan sources merged
- 13+
- free trial
- 14 days

What it does
One fan graph
Fans from Spotify, Meta, Reddit, Discord, Bandcamp, live shows, the email list and more become one record per person, with growth metrics and audience overlap.
Decides what is worth doing
A deterministic Rust engine weighs every eligible action, predicts its outcome before acting and learns from what actually happened. Doing nothing is a valid choice, and sometimes the best one.
Acts inside limits you set
Per context it can observe, recommend, ask for permission or act alone. Confidence thresholds, daily quotas and a global kill switch apply to every action.
Measures, then argues with itself
Actions run with randomised holdouts, so it can tell a fan who arrived because of an action from one who would have come anyway. Beliefs that overclaim get weakened.
Tickets and QR check-in
Stripe takes the payment; passes carry an opaque signed reference, never personal data. Check-in is atomic, so the same ticket can’t get two people in.
Draws anyone can verify
Referral-weighted draws for merch and tickets are reproducible from a revealed seed, with a commitment published to the Sigstore Rekor transparency log.
A closer look

How it's built
PostgreSQL is the source of truth. Every public command writes its business rows, its idempotency record and an outbox event in one transaction. Providers are called afterwards, at least once, and consumers deduplicate, so the API never waits on an email or a third-party call.
Language models are workers, not the boss. They gather and draft; the Rust engine owns the strategy, the evidence, the budget and the final decision.
- Rust
- Axum
- PostgreSQL
- TypeScript
- Rust workspace: domain (pure policy), application (use cases, no SQL), infra, api, worker and the decision engine
- Axum and SQLx on PostgreSQL, with a typed TypeScript client and an OpenAPI contract
- Transactional outbox with signed webhooks, retries with backoff and a dead-letter queue
- Push via FCM and Web Push; delivery counts only after the device confirms it showed the notification
- Fan, staff, admin and control-plane surfaces kept apart by path-prefix authorization
Writing about CrowdRelay
All postsTeaching CrowdRelay Autopilot to learn from its own decisions
Deterministic state machines made CrowdRelay safe and repeatable, but they couldn't learn which actions grew a fanbase. This is how the Autopilot now forms beliefs, tests them and updates them.
What CrowdRelay Autopilot delivers today
The Autopilot could already make decisions. The past weeks added what makes them land: supply requests, evidence-backed pitch waves, verified placements, ramped sending and a quiet daily brief.
CrowdRelay Autopilot should remember deadlines, not run the band
ViryaOS got useful once I made its automation accountable: deterministic decisions, bounded authority, execution receipts and a single view of the exceptions that need a person.
CrowdRelay Autopilot makes the boring decisions in deterministic Rust
How CrowdRelay Autopilot turns band data into safe, measured actions with deterministic Rust and explicit limits, without putting an LLM in charge.
Retry versus reissue for one-time tokens in CrowdRelay
A retried CrowdRelay webhook returned HTTP 200 but sent no email, because retention had already removed the one-time token. Recovery needed a reissue instead.
Proof of fair draws without a blockchain
The draw stays local and deterministic. Rekor only proves that a public commitment existed at a specific time.