Best Delivery App Near You — GitHub Finish-Up-A-Thon Submission

RyannB01 — Thu, 28 May 2026 04:30:40 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Best Delivery App Near You is a web app that tells you which food delivery app — Swiggy or Zomato — is actually the best option for your specific area in India, right now.

You type in your area name or pincode (or hit "Use My Location"), and the app returns a ranked list showing which platform is fastest, highest rated, and has the most active offers in your neighborhood. Rankings are explained transparently, and the underlying ML model improves over time as users submit feedback.

This project means a lot to me because it solves a genuinely annoying real-world problem. Every time I want to order food, I open both apps, compare delivery times, check for offers, and then decide. That's a 2-minute ritual I wanted to automate — and it turns out the data problem behind it is surprisingly hard.

Demo

RyannB01 / best-delivery

Best Delivery App Near You

A web application that ranks food delivery apps (Swiggy and Zomato) for any Indian pincode based on real scraped data, scored by a lightweight ML model trained on delivery time, ratings, and offers.

What It Does

A user enters their area name or pincode. The app returns a ranked list of delivery apps available in that area, showing which is fastest, highest rated, and has the most active offers. Rankings are explained transparently and improve over time as users submit feedback.

Tech Stack

Layer	Technology
Frontend	Vanilla JavaScript, HTML, CSS
Backend	Python, FastAPI
Scraping	Playwright (Zomato), requests (Swiggy)
ML Model	scikit-learn RandomForestRegressor
Geocoding	Nominatim (OpenStreetMap) — free, no API key
Pincode lookup	India Post API — free, no API key
Database	CSV files (raw + engineered features)
Deployment	Vercel (frontend), Render (backend)

Architecture

User enters pincode/area
        │
        ▼
Frontend (Vanilla JS)
  - Calls GET /rank?area=kochi

…

View on GitHub

The Comeback Story

Where it started

The project existed as a rough idea with a half-working scraper and no real structure. I had:

A Playwright script that sometimes captured Zomato responses and sometimes didn't
A Swiggy scraper that only worked for hardcoded city-center coordinates
No backend, no ML model, no frontend
A pile of JSON files from manual browser sessions

The core problem I kept hitting: no public APIs exist for Indian food delivery apps. Swiggy discontinued their public API years ago. Zomato's is B2B only. Blinkit has none. Everything had to be scraped, and scraping is fragile.

What I changed, fixed, and added

Scraper overhaul:

Swiggy now uses precise pincode-level coordinates via Nominatim (OpenStreetMap's free geocoding API) instead of hardcoded city centers. This means two pincodes in the same city get different restaurant lists, which is how the apps actually work.
Zomato scraping was rewritten to use Playwright's response interception (page.on("response", ...)) to capture the webroutes/search/home API call instead of trying to parse the DOM — much more reliable.
Added stealth JS injection to avoid bot detection.
Added India Post API integration to resolve any Indian pincode to a city name automatically.
Pre-scraped 28 cities across India.

On-demand scraping:

When a user searches for a pincode not in the database, the frontend automatically calls /refresh, which triggers a live scrape, runs feature engineering, reloads the data, and then returns rankings. New cities are added automatically without any manual intervention.

Full ML pipeline:

feature_engineering.py cleans raw scraped data and computes a hand-crafted score (delivery time 35%, rating 30%, fee 15%, offers 10%, distance 10%).
train.py trains a RandomForestRegressor on those scores. Initially it replicates the formula; over time it learns from real user feedback — a simplified version of the Learn-to-Rank approach used by Google and Amazon.
retrain.py adjusts training scores based on helpful/not helpful votes and retrains the model.
Model performance on current data: Train R² ~0.99, Test R² ~0.97, Test MAE ~1.5 points on a 0–100 scale.

FastAPI backend from scratch:

/rank — queries engineered features, runs the ML model, returns ranked apps with stats
/refresh — on-demand scrape pipeline triggered by the frontend
/explain — returns feature importances from the trained model
/feedback — stores helpful/not helpful votes, persisted to a JSONL file
/retrain — retrains the model on collected feedback

Frontend:

Single-page app in vanilla JS, HTML, CSS — no framework, no build step.
Category chips (Pizza, Burger, Biryani, etc.) that auto-re-rank when switched.
"Use My Location" via browser geolocation + Nominatim reverse geocoding.
"Why this ranking?" panel with animated feature importance bars.
Helpful/Not helpful feedback buttons on each result card.
Graceful handling of the on-demand scrape flow with a loading state that explains what's happening ("New area detected — scraping live data, this takes ~2 minutes...").

My Experience with GitHub Copilot

Copilot was genuinely useful throughout this project, but in specific ways — not as a magic wand.

Where it saved the most time:

The Swiggy API response parsing was the most tedious part. The response is a deeply nested JSON with inconsistent structure — restaurants are buried inside data.cards[n].card.card.gridElements.infoWithStyle.restaurants. Copilot autocompleted the entire nested access chain after I typed the first two levels, and got it right. That alone saved 20 minutes of trial-and-error.

For the FastAPI endpoints, once I wrote the first endpoint (/rank) with full docstrings and type hints, Copilot generated accurate skeletons for /feedback, /retrain, and /health that needed only minor edits. It understood the pattern from context.

The feature engineering scoring formula was another win. I described the weights in a comment (# delivery time 35%, rating 30%...) and Copilot wrote the normalized score calculation correctly on the first try, including the .clip() calls to handle outliers.

Where it needed guidance:

The Playwright scraping logic required more back-and-forth. Copilot's initial suggestions used page.wait_for_selector() on DOM elements, which doesn't work well for a React app that renders asynchronously. I had to steer it toward the response interception approach (page.on("response", ...)) which is more reliable. Once I showed it that pattern in a comment, it followed it correctly.

The on-demand scrape flow in app.js — where the frontend catches a 404, calls /refresh, waits, then retries /rank — was something I had to write manually. Copilot kept suggesting simpler error handling that didn't account for the 2-3 minute scrape time.

Overall:

Copilot is best described as a very fast typist who has read a lot of code. It handles boilerplate, repetitive patterns, and well-known API structures extremely well. For novel logic — like the fallback chain in the scraper or the feedback-adjusted retraining — you still need to think it through yourself and use Copilot to execute the implementation. That's a fair division of labor.

The project took about a week of evenings. The code itself probably represents 3-4 days of work; the rest was data validation, testing the scraper against real pincodes, and debugging Zomato's bot detection. Copilot helped with the code. The data problem required human time.

Built with FastAPI, scikit-learn, Playwright, Vanilla JS, Nominatim, and India Post API. No paid APIs.

DEV Community: RyannB01