Forkery tells you whether a recipe works, going only by the people who actually made it.
Paste a recipe link or a YouTube cooking video. Forkery reads the comments (up to the 400 newest) and asks three things about each one: did this person cook it, did it turn out, and what did they change. "Looks delicious, saving this!" doesn't count. "Made it twice, halved the salt the second time" does.
You get one card: how many people cooked it, how often it worked for them, and the changes they made most. Tap any number and you see the exact comments behind it, each linked back to where it was posted.
Try it at forkery.dev. It's a working preview; the accuracy work isn't finished yet, and Evaluation says where it stands.
Star ratings mix people who cooked a recipe with people who liked the photo. The useful part is in the comments ("too salty, halve it", "needs 10 more minutes"), but a popular recipe has hundreds of them and nobody reads them all.
A large language model could read them, but not cheaply enough to do it for every recipe someone pastes. Forkery uses Jev, a decision model from TypeSafe, which answers a fixed list of questions about a piece of text and says how sure it is about each answer. That's the job here, and it's cheap enough to run on every comment.
The code is private. This repo explains what Forkery does, why, how it's built, and how well it works so far.
Short on time? Read these three:
- Vision and strategy: where Forkery is going, and the bet behind it
- How Forkery uses Jev: what the model does, in 2 minutes
- Decisions: the calls I made along the way, and what each one cost
The documents are grouped by who would normally own them on a product team.
Product management (docs/product/), in the order they're usually written:
| Document | Read it for |
|---|---|
| 01 Vision and strategy | Where Forkery is going, and the bet behind it |
| 02 Project charter | Why the project was started, its goals, budget, limits and when to stop |
| 03 User research | What the evidence says about cooks, working personas, the riskiest assumptions and how to test them |
| 04 Competition | Who else works on this, where Forkery is different, and what could close the gap |
| 05 Product requirements | What the product does, requirement by requirement, and what's built |
| 06 Roadmap | What's now, next and later, and why in that order |
| 07 Metrics and experiments | The one number that says it's working, how it's tracked, and two tests to run |
| 08 Business model | What it costs to run and how it could pay for itself |
| 09 Launch plan | What has to be true before launch, who it's for, and the post-launch review |
| 10 Status update | Where things stood at the end of September 2026 |
Business analysis (docs/business-analysis/):
| Document | Read it for |
|---|---|
| Business requirements | The problem, who it's for, and what the business needs |
| Glossary and business rules | What every term on the card means, and every rule that decides what's counted |
| Process map | How cooks judge a recipe today, how that changes, and how removal requests work |
| User acceptance test plan | How real cooks will check the card is right before launch |
Engineering (docs/engineering/):
| Document | Read it for |
|---|---|
| How Forkery uses Jev | What Jev is and the one job it does here: a 2-minute read, then the technical details |
| Architecture | How a pasted link becomes a card |
| Security | What keeps a public tool from being misused |
| Evaluation | How accurate it is so far, and what hasn't been measured |
Across all roles: Decisions, the log of what was decided, what it cost, and why.
Happy to walk through the code on request.
All rights reserved. See LICENSE.