case study · discord bot
I built a Discord bot for TAMU ColorStack's 100+ member server. Members fill out one profile form, check in to events with a short code, and look up their own points. Officers don't touch attendance data at all.
The chapter talks on Discord, but attendance lived in Airtable.
The form was long enough that people skipped it, so the attendance numbers were low before anyone even looked at them.
Before writing code I talked to the officer board and to members after meetings, and I kept asking them between releases. A few things came up over and over:
| goal | how i measured it | target | result |
|---|---|---|---|
| active members verified | % of active members linked to a directory row | 80% | ~85% |
| fast check-in | time for one member to check in | under 1 min | under 1 min (was ~5) |
| no manual point tracking | officer time spent on attendance and points | ~0 | ~0 |
| members can do it alone | members who needed help to verify | a handful | 3 |
| always on | outages this semester | 0 | 0 |
Officers already work in Notion, so the data had to end up there. Notion's API is rate-limited, though, and a bot that waits on it would stall when a room checks in at once. SQLite takes every write instantly, and a sync worker copies changes into Notion.
Tradeoff: two copies of the data means sync logic, which is where the race condition came from (see architecture).
The Airtable form asked for the same details at every event. Now members fill out the Notion member form once, and the bot links it to their Discord account. After that, checking in is a single command with the event code.
Exact matching locked out real members with messy records, and approving everyone by hand doesn't scale to a 100+ person server. The bot tries an exact match, then a looser one, and only sends what's left to an officer.
Anyone can click a reaction from home, and QR needs a screen at every event. A short, time-limited code read out in the room shows you were there and works at a volleyball practice as well as a general meeting. QR is next on the roadmap as an extra option.
The officer board changes every year. Because permissions follow Discord roles, handing the bot over means reassigning roles, with no code change or redeploy.
SQLite keeps check-ins fast and correct. Notion is where officers read the data. The bot never waits on Notion before answering a member.
Early on, two things could touch the same member at once: a check-in awarding points and the sync worker pushing that member to Notion, or two check-ins landing together. Both read the row, both computed a new total, and whichever wrote last won. Points disappeared without any error.
I fixed it with a per-member asyncio.Lock around every read-modify-write and a version number on each row. The sync worker takes the same lock, snapshots the row, pushes it to Notion, and only clears the dirty flag if the version is unchanged.
async with locks[member_id]:
row = db.get(member_id)
row.points += award
row.version += 1
row.dirty = True
db.save(row)New members see a "Get Verified" message. It's registered as a persistent view, so the button still works after restarts and redeploys. Clicking it opens a modal for name and email, and then the matcher runs:
A match gives the member the Member role and their class-year role and links their Discord ID to the directory row.
Every command declares a minimum tier: member, officer or admin. One check maps the user's Discord roles to a tier before the command runs, so members never see officer commands like starting attendance or adjusting points. A new officer gets access as soon as their role changes.
The bot runs in a Docker container on Fly.io, with the SQLite file on a persistent volume and the bot token and Notion key in Fly's secret store. Shipping a change is one deploy, and no laptop has to stay on. It has run since August without an outage.
I shipped small versions, watched how officers and members used them, and let their feedback decide what came next.
Numbers from the Notion event log, Sep 13 to Oct 6, 2026:
