The Problem

Real‑estate agents often receive repetitive property queries that waste staff time. A lightweight web‑based chatbot that can instantly match a user’s question to a curated FAQ reduces manual effort and improves response consistency.

What This Does

The repository implements a Flask server (app.py) that exposes a single web UI (HTML in templates/ and static assets). User input is posted to the backend, where the question is vectorised with TF‑IDF (see data/qa_data.py) and matched via cosine similarity against a hard‑coded list of 50+ Q&A pairs (feedback_data.json). The matched answer is returned and rendered in the chat window (static/js/script.js).

Key files:

  • app.py – creates the Flask app, loads the QA data, defines the / and /get routes.
  • data/qa_data.py – builds the TF‑IDF matrix and provides find_best_match(question).
  • templates/index.html and static/js/script.js – UI and client‑side request handling.

How It Is Wired

Execution starts with python app.py. The script:

  1. Imports qa_data (from data import qa_data) and app_secrets (holds placeholder secrets).
  2. Instantiates a Flask app and calls qa_data.load_data() to read feedback_data.json and compute the TF‑IDF matrix.
  3. Registers the root route (/) that renders templates/index.html.
  4. Registers the AJAX route (/get) which extracts the posted question, calls qa_data.find_best_match(question), and returns the answer as JSON.

The only outward effect is the HTTP response; the code never writes to a database or external service. The widest blast radius is app.py because it is the sole module importing qa_data; any change to the matching logic propagates through the single request handler. No circular imports are present, and the internal call graph shows a single edge (app.py → data/qa_data.py).

Static assets (static/js/script.js) fetch the answer via fetch('/get', …) and inject it into the DOM. The script contains deep nesting (max indentation depth 7), making future UI tweaks harder to follow.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/Real-Estate-Chatbot.git
cd Real-Estate-Chatbot

# Create a virtual environment
python -m venv venv
source venv/bin/activate   # Windows: venv\Scripts\activate

# Install Python dependencies
pip install -r requirements.txt

# (Optional) Create a config file if you need ngrok tunnelling
#   The README mentions a config.py with NGROK_AUTH_TOKEN, but the repo
#   does not contain or import this file. It can be added if external
#   tunnelling is required.

# Run the Flask server
python app.py

The server starts on http://127.0.0.1:5000. Open that URL in a browser to interact with the chatbot.

Real‑World Use

A property portal can embed the chatbot widget on its listings page. When a visitor asks “What is the deposit for a 2‑bedroom apartment?” the client script sends the query to /get; the Flask backend returns the pre‑matched answer, eliminating the need for a live agent to handle that query.

Code Health & Issues

  • High – No LICENSE – repository root lacks any licence file; reuse is legally blocked.
  • High – Debug mode enabled – app.run(debug=True) in app.py exposes full tracebacks and a remote shell in production.
  • Medium – Dependabot missing – only one manifest (requirements.txt) and no automated dependency updater configured.
  • Medium – Large binary in repo – images/user.png (6 MB) inflates clone size; should be moved to Git LFS or external storage.
  • Medium – Deep nesting – observed in app.py and static/js/script.js (max indent 7), reducing readability.
  • Medium – High branching density – data/qa_data.py contains 155 branch points in 220 lines, suggesting the matching logic could be refactored into a clearer dispatch table.

Additional observations: no test suite, no CI/CD pipeline, no lockfile for pip dependencies, and app_secrets.py contains placeholder secret paths.

The Bottom Line

The chatbot provides a functional, Flask‑based Q&A front‑end with minimal setup, suitable for quick demos or internal tools. However, production use is hampered by security (debug mode), licensing uncertainty, and code‑maintainability concerns (deep nesting, branching). Adding tests, a CI pipeline, and cleaning up secrets would make the project far more robust for client deployments.