How I stopped running Virya from memory

For a while the operational side of Virya lived in four places: Google Sheets, Gmail, Discord and somebody's memory. Usually mine, which was flattering but didn't scale.

We had thousands of old records, festival applications, booking contacts, media files, EPK links, replies, deadlines and follow-ups. The data existed. The process connecting it didn't.

One job per tool#

I didn't replace every tool. I gave each one a clear job. Google Sheets stayed the human-editable CRM, Gmail the communication channel, Drive the file cabinet, and Discord the place where the team sees what needs attention. n8n became the orchestration layer instead of a source of truth, while CrowdRelay took the durable product state that needs transactions, permissions, retries and explicit lifecycles.

n8n with code where it helps#

The useful version of n8n isn't pure no-code. Mine is visual orchestration around small deterministic code blocks, APIs, manual checkpoints and logs. A person can follow the broad flow without reading a repository, and I can still write JavaScript where dragging in another seven nodes would be a punishment for everyone involved.

Preparation and sending are separate#

The first hard rule was separating preparation from sending. The system may find a candidate, normalise the record, score it, prepare a Gmail draft and post a preview to Discord. It may not silently send cold outreach. Every external action has an explicit status and an approval point.

An audit record for every run#

Every run also writes an audit record. Did the workflow start? How many rows did it read? Which API failed? Did it create anything new, or was everything already known? That sounds basic until a green Meta credential sits next to five failed requests and somebody has to work out which part of the path is broken.

From raw rows to records#

One registry run scanned 3,991 rows and turned raw social links into 500 stable targets. The number mattered less than the change behind it: a spreadsheet column full of URLs became records with IDs, priorities, access modes and visible state. That pattern now repeats everywhere:

raw data → normalised record → stable identity → action → audit

Where AI fits#

AI handles the ambiguous bits: is this a festival or a radio show, does it fit our music, is the reply positive, what's the useful next step, and can the email be written around one real reason to contact them? The workflow handles the parts that shouldn't be creative.

Why I built it#

I didn't build this to automate every minute of the band's life. I built it because copying the same EPK link into similar messages is a poor use of anyone's best hours.

I'd rather write music, solve an interesting engineering problem, spend time with my family or simply do nothing for a while. The system gives me back some of that time.