The Poll That Needed a Database
Two poker tools that deliberately have no backend, and the third one that could not get away with it.
Getting six people to agree on a Thursday is harder than the game itself. Someone suggests a date, two people reply, a third replies to the wrong message, and by the time it settles you have scrolled past forty messages and nobody is certain what was decided. So I built a poll: put up three or four candidate Thursdays, send one link, everyone taps the nights they can make.
The interesting part is not the poll. It is that this is the first thing on the site that needed a server, and I had spent the previous two poker tools proving I did not need one.
The Rule I Had Been Enjoying
The Cash-Up calculator holds nothing. The Ledger keeps the whole table in the browser, and when I needed to hand the game to someone else mid-night, I packed the entire table into the URL rather than adding a database. I wrote about that at the time, because it felt like a small victory: the link was the database.
That trick works because a handoff has exactly one writer. I hold the state, I encode it, you decode it, and now you hold it. The link is a snapshot passed from one hand to the next.
A poll is the opposite shape. Six people all need to write to the same record, at the same time, from six phones, and every one of them needs to see what the others said. There is no clever encoding that gets you out of that. I spent about ten minutes looking for one anyway, which I mention because the honest version of this story includes the ten minutes.
What a Database Asks You
Adding storage is easy. What storage actually costs you is a set of questions you did not have to answer before, and the awkward one here was permissions. There are no accounts. There is no login. Anyone holding the link can read the poll and vote, which is exactly the model Doodle and Rallly use and exactly what I want. But some things should not be open to everyone with the link, and the moment you say that out loud you have to decide who anyone is.
The two actions that needed protecting were locking in a date and deleting the poll. Both belong to whoever started it. Since there are no accounts, the closest thing to identity I have is a random token generated when the poll is created and kept in that person's browser.
My first instinct was to store that token on the poll itself, which is wrong in a way that is worth saying plainly: the poll is readable by anyone with the link, so the token would have been sitting in the response for anyone to copy. A secret you hand out with every page load is not a secret. It lives in its own table instead, one with permission to be written and no permission at all to be read. The only thing that can see it is the database function that checks it. If a guest forges the request, Postgres refuses, rather than the button simply being hidden from them.
Counting Is Not Deciding
The version I built first named a winner. Most votes took the top spot, and when two nights drew level it quietly preferred the earlier one. That is the sort of rule that seems helpful when you write it and is faintly annoying when you use it, because the tie is real information and the tool had swallowed it.
It now reports ties and refuses to break them. Two nights level on four says so, and then it stops, because the person who knows that Tom is dependable and Michael is not is the person running the game. The tool counts. Deciding is a separate job, and it belongs to whoever is hosting.
That distinction turned out to shape the rest of the design. The host locks in the night, the host deletes the poll, and everyone else gets one clean job: tap the dates you can make and submit. The people voting do not even see the share buttons, because they already have the link.
Where It Ends Up
Three tools now, one for each stage of the evening. Pick the night, run the table, settle up. They finally share a landing page and a set of tabs, which took embarrassingly long to add given that the whole complaint was about not being able to find things.
The no-backend rule was never really a rule. It was a preference, and it held for two tools because those two tools genuinely did not need a server. This one did, and the useful discipline was not avoiding the database. It was being clear about the one thing it was allowed to do.