Why We Built RecipeScrape — And Why We're Giving It Away

Every developer who's tried to build a cooking app has run into the same wall: recipe data is everywhere and nowhere. RecipeTin Eats has amazing recipes but no API. Allrecipes has an API but it's gated behind a partnership deal. TheMealDB is free but tiny. Spoonacular has everything but gets expensive fast.

RecipeScrape started as a frustration-driven side project. What if you could scrape structured recipe data from the best sites on the web, normalize it into a consistent format, and serve it through a clean REST API — all without charging per-request fees?

The First Prototype

The initial version was a single Python script that scraped one site (RecipeTin Eats) and dumped JSON files into a Git repo. Ugly, simple, and surprisingly useful. A friend building a meal-planning app asked for access, then another friend, then a stranger on Reddit. That's when we realized the JSON dump approach wouldn't scale.

From JSON Files to PostgreSQL

The database flipped everything. Suddenly we could run full-text search, filter by cuisine and prep time, and serve random recipes without loading the entire collection into memory. The move to Neon PostgreSQL cost $0 (the free tier handles 7,000+ recipes easily) and unlocked features that would have been impossible with flat files.

Why Free?

RecipeScrape remains free because the economics work: scrapers run on GitHub Actions (free), the frontend deploys on Vercel (free tier), and the database is Neon's free tier. The only real cost is time — and we genuinely enjoy building it.

If the project ever needs to pay for itself, RapidAPI handles monetization transparently. But the public API at recipescrape.vercel.app will stay free for non-commercial use. Always.

What's Next

The roadmap includes more source sites, multi-language search, ingredient substitution suggestions, and a GraphQL wrapper. But the core mission stays the same: every recipe, one API.