CoreySafebites - a trust layer for eating out
Knowing whether a dish is safe for you, before you order - not after a research project.
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.
What this is, on the record
- Started
- 24/06/2026
- Commits
- 9
- Status
- Live, early
- Who did what
- Built by Kristian Papadakis with Corey running the build sessions. Early, and labelled early.
- Built with
- Astro, Postgres, Cloudflare Pages
The project
Safebites is about trust around food. If you have an allergy, an intolerance or a condition that makes eating out a calculation, the problem is not that the information does not exist. It is that getting to it takes longer than the moment you have.
You are standing in front of a menu. You need a clear answer. What you get instead is an ingredients list that may or may not be current, a member of staff who may or may not know, and a decision made on incomplete information.
So the work is not really data collection. It is turning messy information into a single confident answer at the moment someone has to commit.
What we did
The public site was built in three planned slices over roughly two weeks in mid-2026.
The first shipped public place pages - static, trust-labelled, with structured data so search engines and language models can read them properly. The second added a page per dish and a sitemap index across the whole set, so individual dishes became findable in their own right. The third added the directory itself, with search and filtering running client-side.
Each slice was independently useful. That was the point. At no stage was there a half-built thing that only made sense once the next part landed.
Where it actually is
Early. The public directory is live and the shape is clear, but this is a product finding its footing rather than a finished one.
That is worth saying plainly. There is a strong pull, when writing a case study, to describe an early project in the language of a launched one. Resisting it is the same discipline that runs through everything else here - if we will overstate this, why would you believe the rest?
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.
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.
Run yours the same way
Everything above is one operator across a portfolio. Corey is that operator, packaged. 28 days on us, no card.