Data Scraping & Aggregation

A Search-First Recipe Ingredient Platform With Self-Refreshing Imagery

How Pfactorial Technologies built a Flask and MongoDB application that turns a dish name into ingredients, measurements, and images, kept current through automated scraping.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client needed a tool that could turn a dish name into a usable ingredient list - names, measurements, and images - instead of a cook or recipe developer piecing that together by hand from scattered sources.

A static recipe database doesn't solve this: ingredient images and current listings aren't something you can hand-maintain at any scale, the data has to be fetched and kept current on its own, and the search interface has to feel instant rather than like a form submission.

Pfactorial built Chef Scan: a Flask and MongoDB application that pairs a rule-based ingredient lookup with Selenium-driven image scraping, wrapped in a live search-and-autocomplete interface and a feedback loop back to the team.

Why this engagement is representative This engagement demonstrates Pfactorial's ability to pair a lightweight rule-based backend with automated web scraping to keep a content-driven product current without manual data entry.

THE CHALLENGE

Turning a dish name into a complete, visual ingredient list meant solving data-freshness and interaction problems a static database wouldn't.

1. Ingredient images can't be hand-curated at scale

Selenium-driven scraping fetches ingredient imagery automatically, rather than requiring someone to source and upload a photo for every ingredient in the system.

2. Search has to feel instant, not like a form submission

The frontend fetches and renders suggestions as the user types, rather than waiting for a full page reload on every query.

3. Ingredient data and dish data are two different shapes

menu.json and final_data.json represent sample menu data and processed ingredient data separately, and both have to resolve into one consistent result on the ingredient list page.

4. User feedback needs a path back to the team without new infrastructure

The contact form logs directly to a timestamped CSV file, giving the team a lightweight audit trail without standing up a separate feedback system.

The real brief Not "a static recipe database" but "a search experience that returns ingredients, measurements, and images live, kept current by automated data collection."

THE SOLUTION

Pfactorial built Chef Scan around a Flask backend, a MongoDB ingredient store, and a Selenium scraping layer that keeps ingredient imagery current.

Figure 1 - Every search resolves against one collection; imagery is enriched ahead of time, not fetched live during the request.

Architectural principles

Rule-based recommendation over a heavier ML model - Ingredient matching runs as a direct MongoDB query against a curated collection, which is simpler to reason about and maintain than a trained recommendation model at this catalog size.
Scraping as an enrichment layer, not the request path - Selenium fetches and stores ingredient images ahead of time rather than scraping live during a user's search, so a slow or blocked source degrades freshness, not response time.
One collection, multiple concerns - Names, images, and quantities all live in the ingredientList collection, keeping the read path a single query instead of a join across services.
Feedback captured without new infrastructure - The contact form's CSV log gives the team a lightweight, dependency-free channel for user feedback rather than requiring a support-ticket system for an MVP.

CAPABILITIES DELIVERED

Each capability replaces manual recipe research with an automated lookup or an automated data-collection step.

CAPABILITY	WHAT IT DOES
Dish-to-ingredient search	search_recipe() queries MongoDB for ingredient names, quantities, and images matched to a dish name.
Live search autocomplete	index.js fetches and renders suggestions as the user types, without a full page reload.
Automated ingredient imagery	Selenium scraping keeps the static/Images directory populated with current ingredient photography.
Contact & feedback capture	A popup contact form logs submissions to a timestamped CSV file for the team to review.
Structured data ingestion	menu.json and final_data.json feed sample and processed ingredient data into the same MongoDB-backed index.

Figure 2 - One query touches one collection; images stay current without touching the request path.

Design note Scraping runs as a background enrichment step that populates the image store ahead of time, rather than a live call inside the request path - the tradeoff is images can lag a source update, but a slow or blocked scraper never turns into a slow search response for the user.

ENGINEERING FOR SCALE AND RELIABILITY

Four decisions kept the app simple to run and cheap to operate for its scale.

MongoDB over a relational schema

Ingredient records vary in shape - name, image path, quantity, unit - which fits a document store more naturally than a fixed relational table.

Selenium for image collection instead of a paid image API

Scraping ingredient photography avoids licensing costs for a catalog-sized image set, at the cost of needing to tolerate source-page changes over time.

Docker and Gunicorn for deployment

Containerizing the Flask app behind Gunicorn gives a repeatable deployment path and the concurrency a single-threaded dev server wouldn't provide.

CSV logging instead of a database table for feedback

Feedback volume didn't justify a dedicated table or service; appending to a CSV file with a timestamp is enough for the team to review submissions.

DELIVERY APPROACH

The build moved outward from the data layer to the interaction layer.

1. Data modeling - standing up the chefscanIngList MongoDB database and the ingredientList collection as the single ingredient source of truth.

2. Search backend - building search_recipe() in app.py to query MongoDB and return matched ingredient data to the frontend.

3. Image collection - building the Selenium scraping layer that populates static/Images with ingredient photography.

4. Frontend interaction - shipping index.js for live autocomplete, popup contact-form handling, and the typing-animation header, on top of the index.html template.

RESULTS AND IMPACT

- Key outcomes from this engagement.

Chef Scan gives users a single search that returns ingredient names, measurements, and images for a given dish, backed by one MongoDB collection rather than data assembled by hand.

Because ingredient imagery is collected automatically through Selenium rather than uploaded manually, the catalog can grow without a proportional increase in content-team effort, and the Docker and Gunicorn deployment gives the client a repeatable path to running the app in production.

What it enabled commercially

The client can offer ingredient search as a self-service product feature - with imagery that stays current through automation rather than manual curation - deployed on standard containerized infrastructure rather than a bespoke hosting setup.

WHY PFACTORIAL

This engagement reflects Pfactorial's practice of pairing pragmatic, rule-based backends with automated data collection, so a content-driven product stays current without a manual-curation team behind it.

- Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with organisations that need a content- or catalog-driven product kept current through automation rather than manual entry. If you're scoping a search or recommendation feature backed by data that needs to stay fresh, we're happy to talk through what's realistic to automate. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.

Result and Analysis

ENGAGEMENT SNAPSHOT

How Pfactorial Technologies built a Flask and MongoDB application that turns a dish name into ingredients, measurements, and images, kept current through automated scraping.