Back to Projects
Foodify
CompletedDartFlutter

Foodify

Recipe browsing and recommendation app — final year BSc Computer Science project

Timeline

Mar 2022 — Nov 2022

Role

Solo

Team

Solo

Status
Completed

Technology Stack

Dart
Flutter

Key Challenges

  • Building a recipe recommendation engine that balances three signals at once — diet preference, calorie target, and course — without over-filtering the candidate set into an empty list
  • Bridging a Python ML backend (Flask + gensim + nltk + scikit-learn + pandas) with a Flutter mobile frontend and keeping the data contracts stable between the two
  • Sourcing and scraping a recipe dataset large enough to be useful, then cleaning it into a shape the recommender and the search engine could both consume
  • Wiring up Amazon Fresh deep links for ingredient shopping in a way that gracefully degrades on devices without the app installed

Key Learnings

  • How to stitch together gensim, nltk, and scikit-learn into a single content-based recommendation pipeline — tokenisation, vectorisation, and similarity scoring each have their own footguns
  • Why a clean frontend/backend split in two separate repos paid off when we had to iterate on the recommender without rebuilding the Flutter app
  • The practical difference between Firestore queries and a dedicated search engine (MillieSearch) — Firestore for structured user data, MillieSearch for full-text recipe search
  • Shipping a final-year project to the Play Store teaches you all the boring lessons gitignore never warns you about — signing keys, version bumping, and store listing copy

The Problem

By my final year of BSc Computer Science, I wanted to build something I'd actually use. The idea behind Foodify came from a frustration I had every evening: I'd open three different apps just to answer one question — "what can I cook tonight that fits my diet, doesn't blow my calorie budget, and uses the onion that's about to go bad in my fridge?" Recipe apps either assumed I had every ingredient, ignored my dietary constraints, or pushed me toward sponsored content. None of them treated the leftovers in my kitchen as a first-class input.

So for our final-year project, Prativa Chakraborty and I set out to build a recipe browsing and recommendation app that would take all three signals — diet, calories, and course — and also let you flip the script and start from whatever's in your fridge.

What I Built

Foodify is a Flutter mobile app backed by a Python recommendation service. You sign in with Firebase Auth, browse a curated recipe catalog, get personalised suggestions based on your dietary profile, search by name or ingredient, or punch in the ingredients you already have and get back recipes you can make right now. When you find something you like, the app hands you a direct link to Amazon Fresh to buy whatever you're missing.

It shipped to the Play Store as com.softperks.foodify — a real, installable artefact, not just a Git repo with a README and good intentions.

Architecture

The repo is split into two clear halves, which kept our collaboration clean:

FrontendFrontend/foodify/

  • Flutter (Dart) for the mobile UI
  • Firebase Authentication for sign-in
  • Cloud Firestore for user profiles, favourites, and the structured recipe catalog

BackendBackend/

  • Python (Flask) for the recommendation HTTP API
  • gensim, nltk, scikit-learn, pandas for the recommendation pipeline and the recipe scraper
  • MillieSearch as the dedicated full-text search engine over the recipe corpus
  • Firebase for auth tokens and any structured data the mobile client needs

The split meant Prativa and I could work in parallel — Flutter changes and Python service changes didn't step on each other, and we could deploy the recommender independently of an app store release.

Mobile app (Flutter + Firebase Auth + Firestore)
        │
        ├── reads/writes structured data → Firestore
        │
        └── personalised suggestions + ingredient search
                │
                ▼
        Flask API (Python)
                │
                ├── gensim + nltk + scikit-learn + pandas
                │       (recommendation pipeline)
                │
                ├── MillieSearch (full-text recipe search)
                │
                └── scraped recipe dataset (pandas)

The Recommendation System

The interesting part of the backend. We combined three signals into a single ranked list:

  1. Diet preference — vegetarian, vegan, non-veg, etc., as a hard filter on the candidate set
  2. Calorie target — a soft penalty that nudged the ranking toward recipes inside the user's daily budget
  3. Course — breakfast, lunch, dinner, snack — used as both a filter and a ranking feature

The pipeline used nltk for tokenisation and ingredient normalisation, gensim for the recipe vector space, and scikit-learn for the final similarity scoring. pandas held the whole thing together as the in-memory data structure for the scraped recipe corpus.

The "ingredients on hand" mode was the fun one to design. You'd type in what you have, and the recommender would score recipes by ingredient overlap with your input — weighted by how essential each ingredient was to the dish. A dish that needed just the onion you had scored higher than a dish that needed seventeen things, even if it only used the onion as a garnish.

Features

  • Personalised AI recipe suggestions based on diet, calorie budget, and course
  • Ingredient-based search — "what can I make with what's in my kitchen?"
  • Full-text recipe search powered by MillieSearch
  • Direct Amazon Fresh links to buy missing ingredients
  • User profiles and favourites backed by Firestore
  • Minimal, friendly UI with simple page navigation

Team

This was a 2-person final-year project. I owned the backend and the recommendation pipeline; Prativa Chakraborty led the Flutter frontend and the Firebase integration. We split the repo along the frontend/backend line, reviewed each other's PRs, and learned the hard way that two people trying to ship a Play Store app in one semester need a very short standup.

Links

Timeline

Built as a final-year BSc Computer Science project with Prativa Chakraborty. The repo was created in March 2022 and the project shipped to the Google Play Store in November 2022 after about eight months of work.

  • Mar 2022 — Repo created; final year BSc CS project kickoff with Prativa Chakraborty
  • Nov 2022 — Flutter frontend + Python recommendation backend (Flask, gensim, nltk, scikit-learn) + MillieSearch + Firebase complete; published to Google Play

Design & Developed by Sudip Ghosh
© 2026. All rights reserved.