An app for a class pizza night: Stripe, allergies and GDPR in a first-grade class

The most delicate project I shipped this year is not the fintech SaaS, not the assisted trading, not the agent orchestrator. It's the website for the first-grade class end-of-year pizza dinner.

A whole class, some thirty families. A pizzeria in Parma. A Wednesday in June, 7:15 pm. And a pile of non-functional requirements worthy of a public procurement tender.

The brief (three days before registrations closed)

The starting brief asked for: family registration without login, one person signing up the whole family, children's data including allergies, who pays what, and a till that collects exactly the set amounts. Deadline: yesterday, more or less — between opening the project and closing registrations there were three days. Then, in the scoping chat, the scope grew on its own: each adult's drink, and the table seating plan.

An agent and I stood the app up in a few days: Next.js, database, payments, email. So far, routine vibe coding. The interesting parts — the reason this post exists — are three.

1. The gross-up, or: who pays the pizza's processing fees?

The price was €28 net per adult, €15 per child. But if you collect through Stripe, Stripe takes its cut, and the class's common fund comes up a few dozen cents short per transaction. Multiplied by some thirty families, that's an entire pizza vanishing.

Textbook pricing solution, applied to a school dinner: transparent gross-up. The system computes the fee — 1.5% plus 25 cents, rounded up — and shows it as its own line item: for one adult that's €28 of pizza, €0.69 of "payment fees", €28.69 total. The pizza price stays a round €28, and the fee gets its own line with its own name. Nobody has to take anyone's word for it: you just read.

2. The allergies, or: GDPR doesn't take field trips off

Children's allergies are health data: Article 9, special category, the kind the European regulation does not joke about. Which means: separate explicit consent, restricted access, no cheerful exports into a spreadsheet shared with the world.

But the part I defend hardest is another one: the sunset. The project was born with its death date written in the repository: two weeks after the event, hard deletion of all personal data. Not "let's keep it just in case". Deleted. The most underrated feature in software is the ending.

3. The same-drink-neighbor constraint

Out of scoping came a requirement no product manager would ever dare write: table seats had to respect the "same-drink neighbor" rule — Prosecco people next to Prosecco people, the Spritz front consolidated elsewhere. Sparkling-wine geopolitics, put on record with the serenity of someone ordering an espresso.

We implemented it. Self-service seat selection after payment, with the constraint. It works. It is probably the most absurd database constraint of my career, and I wrote it for a dinner of six-year-olds.

The back-of-the-napkin numbers

• Days of coding: 5, including one night of agents that closed 36 tasks out of 37
• Allergy consents: one of its own, separate from everything else
• Automatic reminders scheduled: 2
• Days between the dinner and the data deletion: 14
• Developer revenue: €0, plus one pizza

And here's the sincere closing, as per family tradition: pro-bono projects are the best laboratory there is. No paying customer stress-tests you like some thirty families with allergic children and opinions about Prosecco. If your stack survives first grade, it survives almost anything.

Second grade, I don't know yet.