# Safebites - a trust layer for eating out

Safebites turns messy allergen and ingredient information into a single confident answer for someone standing in front of a menu. The public site shipped in three planned slices over two weeks - place pages, dish pages and a searchable directory - and it is genuinely early rather than a launch dressed up as one.

These case studies are first-party. Corey is built by Kristian Papadakis for Presso Network, and every business covered is one of ours - not a client, not a commissioned case study.

## The facts
- Venture: Safebites - Knowing whether a dish is safe for you, before you order - not after a research project.
- Status: Live, early
- Started: 24/06/2026
- Commits: 9
- Who did what: Built by Kristian Papadakis with Corey running the build sessions. Early, and labelled early.
- Built with: Astro, Postgres, Cloudflare Pages

## What we decided
- The problem is the moment, not the data: Allergen data exists. What does not exist is a clear yes or no at the point of decision, for someone standing in front of a menu who needs an answer now rather than a research project. Framing it as a decision problem rather than a data problem changed what got built first.
- Static pages over an application: The public site is statically generated onto Cloudflare Pages. For a directory whose content changes far less often than it is read, a database-backed app would have been cost and operational burden for no user-visible gain. It also means every place and dish page is independently indexable.
- Trust labels rather than a score: Places carry explicit trust labelling rather than a single computed rating. A number implies a precision the underlying data does not have, and on a question where being wrong means someone gets ill, overstating confidence is the worst possible failure.
- Ship in numbered slices: Three plans, three pull requests, two weeks - public place pages, then per-dish pages and a sitemap index, then the directory with client-side search and filtering. Each slice was independently useful, so the project was never in a half-finished state.

## What got built
- Public, statically generated place pages with trust labelling and structured data.
- Per-dish pages, each independently indexable, with a sitemap index across the set.
- A places directory with client-side search and filtering, no server round trip.
- Diner-facing and restaurant-facing entry points, plus an early-access route.

## What Corey runs now
- The build sessions: Each slice was planned, built and shipped as its own pull request, with the plan written down before the work started rather than reconstructed after.
- Keeping the public surface healthy: Sitemaps, structured data and internal links checked as part of shipping, so the directory stays indexable as it grows.

## What this became
Safebites is where shipping in numbered slices became a rule rather than a preference. Three plans, three pull requests, two weeks, and the project was useful after each one. That pattern - decide the slice, write it down, ship it, then decide the next one - is how Corey now approaches any piece of work big enough to go wrong. It is also a reminder to label things honestly. Safebites is early. Saying so costs nothing and buys the right to be believed about everything else.

Full page: https://getcorey.ai/case-studies/safebites
