PizzaLeak

When the breach alarm rings, the pizza arrives. Morale-as-a-service for security teams.

Comment

PizzaLeak 🍕

When a confirmed security incident hits a company, PizzaLeak sends the internal security and infrastructure team free pizza — funded by sponsors — for the entire duration of the incident.

💡 Inspiration

Anyone who has sat through a live security incident knows the shape of it: it's 2 a.m., the war room is full, nobody has eaten, and the people holding the line get no thanks until long after the fire is out. We wanted to turn that invisible, thankless grind into a small moment of support — the internet's way of saying "we see you, here's a pizza." Sponsors get to back the defenders; the responders get fed. Everybody wins except the attacker.

🛠️ How we built it

PizzaLeak is a single Next.js app (App Router, TypeScript) backed by Supabase (Postgres + Auth + Row Level Security), with Mercado Pago for sponsor payments and a bilingual ES/EN UI via next-intl. We launched targeting Argentina first, with a country field on every entity so new markets are data, not a rewrite.

The architecture is built around a single trust boundary — is this incident real, and is the reporter actually from the affected team? — with everything else kept deliberately dumb:

  1. Reporter submits an incident and proves they belong to the affected company via a magic link to their corporate email domain (free-mail domains rejected).
  2. A decision engine evaluates it: public incidents are auto-verified against an external evidence link (news, CERT advisory, official statement); private ones pass through rate-limits and anti-fraud checks.
  3. Sponsors (companies) fund a pool through Mercado Pago, tracked in an auditable ledger where every peso flows sponsor_in → fund → pizza_out.
  4. Fulfillment issues a redeemable pizza voucher to the verified team for each interval the incident stays active.
  5. Announcements are consent-gated: public incidents can be named and tag sponsors; private ones only ever appear anonymized — "🍕 sent to a security team handling an active incident."

A design principle we baked into everything: build fully automated, ship with a human switch. The validation and fulfillment engines both run unattended by design but default to human-in-the-loop, flipping to full automation via a single config flag — no code change. Two independent kill switches (decision_mode, fulfillment_mode) let us prove the automation in shadow mode before trusting it with real money.

🧮 A little math

Sponsor money is a shared pool, so how many concurrent incidents we can feed is bounded. If the fund balance is $B$, the cost of one voucher is $c$, the mean incident lasts $d$ intervals, and incidents arrive at rate $\lambda$, the sustainable steady state is:

$$ N_{\text{concurrent}} \le \frac{B}{c \cdot d \cdot \lambda} $$

This ceiling is exactly why fulfillment is gated on a live ledger balance rather than fired blindly — we never promise a pizza the pool can't cover.

🧗 Challenges we faced

  • There is no "order a pizza" API. We researched both PedidosYa and Mercado Pago and found only merchant/POS-side APIs — no buyer-side ordering, no voucher generation. So fulfillment became a pluggable FulfillmentProvider interface with a manual voucher adapter for v1, and a clean seam for a future B2B integration.
  • Proving an incident is real is genuinely hard. You can't programmatically verify a breach, so we split validation into an automatable domain-ownership check and a harder incident-reality check gated by evidence type.
  • The data is radioactive. We learn that a company has an active incident and how to reach its security team. We treated it as sensitive from line one: private-by-default visibility, encryption at rest, RLS, and an anonymization safety-net test that fails the build if a private incident could ever leak a company name.

🎓 What we learned

That the hard part of this idea was never the code — it was the trust boundary and the privacy model. The pizza is easy; deciding who deserves one, without getting defrauded or doxxing a victim, is the whole product. We also learned to design for the integration you wish existed (a clean provider interface) so a missing API becomes a swappable adapter instead of a blocker.

🔭 What's next

A B2B voucher deal with a delivery provider to fully automate fulfillment, flipping the kill switches from manual to auto, and rolling out market-by-market across LATAM.

Built With

Share this project:

Updates