A shared restaurant blacklist that GDPR allows.
A privacy-compliant platform that lets venues protect themselves from repeat no-shows and abusive guests without breaking EU law.
01 · The problem
What Blacklist set out to solve.
A single repeat no-show costs a busy restaurant a fully prepped table on its most valuable night, and the worst offenders simply rebook somewhere else the following week. Venues already keep informal blacklists in spreadsheets and group chats, but those are useless the moment a problem guest walks into a different restaurant. The obvious fix is a shared blacklist across venues, and the obvious reason it does not exist is that, done naively, it is a privacy and defamation lawsuit waiting to happen. Building it in the EU meant the real product was not the list, it was the legal architecture underneath it.
02 · Context and insight
The reframe that set the direction.
Blacklist sits squarely in consumer product territory, except the user being protected is the venue and the data subject is the guest, which is exactly what makes GDPR the hard part. A shared database of named individuals flagged as bad is, in legal terms, the riskiest possible thing to build: reputational, easy to abuse, and a defamation claim away from disaster. The reframe that made it shippable was treating compliance as the core feature, not a checkbox. If a restaurant cannot trust that using the platform keeps them on the right side of the law, no amount of UX polish matters.
03 · The approach
The decisions that mattered.
Anchor the whole product on a defensible lawful basis
Rather than ask guests to consent to being blacklisted, which is absurd, I built the platform on legitimate interest: a venue's right to protect itself against fraud and repeat financial harm. That meant designing the product so every flag is tied to a concrete, documented incident, such as a confirmed booking that became a no-show, not to opinion or reputation. The senior call was accepting a narrower, harder-to-abuse product in exchange for one that holds up to a Data Protection Authority, because a shared blacklist that cannot survive scrutiny is worth nothing to the restaurants relying on it.
Engineer data minimization and erasure as first-class features
The schema stores the minimum needed to match a returning guest and nothing that turns the database into a profile: a hashed phone number, an incident type, a date, and the flagging venue, with no free-text gossip about the person. Right to erasure is wired into the data model from the first migration, so a guest request resolves cleanly instead of cascading through orphaned records. I also built automatic expiry, where a flag ages out after a fixed window, so the platform forgets by default rather than accumulating a permanent record of people.
Design against defamation, not just for usability
The most dangerous failure mode is a venue using the list to settle a grudge, which would expose both the restaurant and the platform to a defamation claim. I removed that vector at the product level: no public list, no shaming, no narrative fields, and matches surfaced only to a venue checking a real upcoming booking. Each flag requires the venue to attest to a factual incident, which creates accountability and an audit trail, so the platform reads as a fraud-prevention tool rather than a rumor mill.
04 · How it's built
Designed and shipped solo.
Roger designed and built Blacklist end to end as a solo project: the legal model, the data model, the interface, and the auth, all of it. The stack is Next.js for the application, Prisma over Postgres for the data layer, with the GDPR constraints encoded directly in the schema rather than bolted on, so erasure, expiry, and data minimization are enforced by the database, not by hopeful application logic. Guest identifiers are hashed at write time so the system can match a returning offender without ever holding a plaintext directory of people, and venue accounts are scoped so a restaurant only ever sees a match against a booking it actually holds. The hardest engineering was making "the right thing legally" and "the right thing structurally" the same decision.
Blacklist proved that the privacy-safe version of an obviously risky idea is the only version worth building. By making GDPR compliance the product rather than an afterthought, it gave restaurants a shared defense against repeat no-shows that they could actually trust to use, onboarding 180+ venues and flagging enough returning offenders to protect a meaningful slice of revenue on their busiest services. The point was never to punish guests, it was to let venues stop subsidizing the small minority who repeatedly burn tables.
What I’d carry forward
The hardest part of a sensitive consumer product is rarely the interface, it is the lawful basis and the failure modes you design out before launch. Encoding erasure, expiry, and minimization into the schema from day one was far cheaper than retrofitting them, and it forced honest decisions about what the product is allowed to remember. The lasting lesson: when the data is about people, restraint in what you collect is a feature, not a limitation, and it is what makes a risky idea defensible enough to ship.