CrowdRelay started from a very practical idea: independent artists should be able to collect their own fan data, see where people actually want a concert and reward the fans who help spread the word. No mysterious advertising dashboard, no platform owning the relationship, no ten disconnected tools held together by exports and hope.
Then the small idea grew teeth
The first flow was innocent enough: a smart link, a registration form and a referral code. Then came double opt-in, consent, unsubscribe, city demand, concert interest, reminders, deterministic rewards, weighted draws, admission passes and QR check-ins. At some point I had to admit that I was no longer building a clever form for Virya. I was building a small event and community backend.
Keep the public request boring
The important part is that the public request stays boring. A person registers and gets a response. The API does not wait for an email provider, Discord, Bandsintown or some other service to have a good day. External deliveries go through a transactional outbox and workers pick them up later. If a provider is down, the registration still exists and the work is still visible.
The website is not the source of truth
The Virya website is only the presentation layer. It can show the counter, the next reward, a concert campaign or a ticket in somebody's wallet, but it does not decide whether any of those things are real. CrowdRelay and PostgreSQL own that state. Staff operations use separate permissions, signed webhooks have replay protection and a QR check-in is an atomic operation — because the entrance to a concert is a terrible place to discover a race condition. :)
Why Rust, actually?
Why Rust? Not because fan forms need absurd throughput. They don't. I chose it because this project is full of explicit states, background work, retries and operations that must happen once even when the network behaves as if it happened zero or two times. Rust makes those transitions easier to see, while PostgreSQL still does the serious durability work through transactions and constraints.
What CrowdRelay became
The project now covers campaigns, smart links, fan accounts, referrals, rewards, draws, event interest, reminders, ticketing and check-ins. There is still plenty I want to add, but it already solves a real problem I know very well from running a band: the data exists, the fans exist and the ideas exist — what is usually missing is one coherent system between them.
You can see the project here: CrowdRelay on GitHub.