DEV Community: Malik Ali Hassan

I Built a RAG Assistant That Explains Your Electricity Bill — Without Letting the AI Invent Numbers

Malik Ali Hassan — Wed, 04 Nov 2026 06:43:47 +0000

Pakistani electricity bills are hard to read even when you're technical. The total jumps month to month, and the bill itself doesn't really explain why — slabs, categories, rates, and surcharges all blur together. Most people just pay it and move on.

I built BijliCheck at a hackathon to attack that confusion directly: a Bill Checker web app with an "Ask about your bill" AI assistant box. You check your bill, then you ask it questions about it in plain English — "why did my bill jump so much?", "how do I avoid this next time?" — and it answers using your actual numbers, not generic advice.

How it works

There are two halves, and the order matters.

First, the Bill Checker. You open the site, fill in your usage, and click "Check my bill." That produces your computed bill numbers: units, category, rate, and total. Nothing about the assistant works without this step, because the assistant's job is to explain these numbers — not to guess at bills in general.

Second, the assistant. It uses retrieval-augmented generation (RAG), in three steps:

Retrieve. Your question is matched against a small local knowledge base of slab rules and billing facts, using keyword-based matching. This runs instantly in the browser — no API call for this step at all.
Augment. The matched facts are combined with your computed bill numbers (units, category, rate, total) into a single prompt.
Generate. That prompt goes to a free LLM (Groq), which writes a plain-English answer grounded in what was retrieved and your numbers.

The user sees the retrieved reference facts listed first, then the generated answer. That ordering is deliberate: you can see what the answer is based on before you read the answer itself.

The design decision that matters most

The assistant is not allowed to invent tariff numbers that were not given to it. That's the whole point of the RAG setup here. A plain chatbot asked about electricity bills will happily produce confident-sounding rates that may be wrong — and a wrong number on a bill is worse than no answer at all. By forcing every answer through retrieved facts plus the user's own computed numbers, the system trades fluency for grounding. The answer might be less smooth than a free-form chat, but it can't hallucinate a slab rate.

There's a second, quieter lesson in the retrieval step: RAG doesn't have to mean a vector database. For a small, well-understood set of facts — slab rules and billing facts — keyword matching over a local knowledge base is fast, free, and runs entirely in the browser. The fancy version of a technique is not always the right version. Match the retrieval method to the size of your knowledge base.

The architecture is deliberately boring

The whole thing is HTML and JavaScript — no framework — hosted on Vercel for free, connected directly to the GitHub repository. The one piece that isn't static is a single tiny serverless function in the api/ folder. It exists for one reason: the API key has to stay secret, and a purely static host can't keep a secret. So the browser does the retrieval, and the serverless function makes the one call that needs the key.

Total setup cost: $0, on Groq's free tier, in about 15 minutes. If the Ask box ever says "offline mode," it means that serverless endpoint isn't reachable — usually the API key wasn't set or the deployment wasn't redeployed after adding it. That's a deployment detail, but it's the kind of thing that eats an hour at a hackathon if you don't know where to look.

Three lessons I'd pass on

Ground the model before you prompt it. Retrieval first, generation second. The order is the safety mechanism.
Show your sources. Listing the retrieved facts before the answer lets the user judge the answer instead of just trusting it.
Keep the demo shippable. A static frontend, one serverless function, and a free-tier model got a working hackathon demo live at zero cost. Complexity can come later, after the idea is proven.

BijliCheck started as a hackathon demo, but the pattern generalises: any domain where the model must not invent numbers — bills, tariffs, schedules, policies — benefits from the same shape. Compute the real numbers first, retrieve the real rules, and only then let the model talk.

Malik Ali Hassan — .NET & full-stack developer, final-year Software Engineering student. I build Python automation, AI assistants, and web apps.

I Wrote a Python Script That Cleans Up Any Messy Folder — and It Never Deletes Anything by Default

Malik Ali Hassan — Wed, 04 Nov 2026 06:38:51 +0000

Everyone has that one folder. Downloads, Desktop, some project directory — hundreds of files, no structure, and the thought of sorting it by hand is so dull you just... don't.

I wrote a small Python script that does it for you. It sorts a folder's files into subfolders by type, and the important part is in the title: by default, it changes nothing. It only shows you what it would do. You have to explicitly tell it to move files.

What it does

Point it at a folder and it sorts every file into one of six categories:

Folder	Extensions
Images	.jpg, .jpeg, .png, .gif, .webp, .svg
Documents	.pdf, .doc, .docx, .txt, .md
Spreadsheets	.csv, .xls, .xlsx, .ods
Archives	.zip, .tar, .gz, .rar, .7z
Code	.py, .js, .html, .css, .json
Others	anything else

No dependencies beyond the standard library — just argparse, shutil, and pathlib. No install step at all.

Usage

python file_organizer.py ~/Downloads            # dry run, no changes
python file_organizer.py ~/Downloads --apply    # actually move files

The dry run prints lines like would move: report.pdf -> Documents/ and finishes with a count. Only --apply performs the moves.

How it works

The whole script is built around one mapping and one function:

CATEGORIES = {
    "Images": {".jpg", ".jpeg", ".png", ".gif", ".webp", ".svg"},
    "Documents": {".pdf", ".doc", ".docx", ".txt", ".md"},
    "Spreadsheets": {".csv", ".xls", ".xlsx", ".ods"},
    "Archives": {".zip", ".tar", ".gz", ".rar", ".7z"},
    "Code": {".py", ".js", ".html", ".css", ".json"},
}

def category_for(path):
    """Return the category folder name for a file's extension."""
    for name, extensions in CATEGORIES.items():
        if path.suffix.lower() in extensions:
            return name
    return "Others"

Extensions are lowercased before matching, so Photo.JPG and photo.jpg land in the same folder. Anything unknown falls into Others rather than being skipped silently — a file you can't find is worse than a file in a misc folder.

The organising function keeps the dry-run and apply paths in one place, so they can never drift apart:

def organize(folder, apply=False):
    folder = Path(folder)
    if not folder.is_dir():
        print(f"error: {folder} is not a folder", file=sys.stderr)
        return 1
    moved = 0
    for path in sorted(folder.iterdir()):
        if not path.is_file():
            continue  # never touch subfolders
        target_dir = folder / category_for(path)
        target = target_dir / path.name
        if apply:
            target_dir.mkdir(exist_ok=True)
            shutil.move(str(path), str(target))
            print(f"moved: {path.name} -> {target_dir.name}/")
        else:
            print(f"would move: {path.name} -> {target_dir.name}/")
        moved += 1
    mode = "moved" if apply else "would move (dry run — use --apply to move)"
    print(f"{moved} file(s) {mode}")
    return 0

Three safety decisions are doing the quiet work here:

Dry run is the default. The destructive action requires an explicit flag. If you run it by accident, nothing happens — you just get a preview.
It never touches subfolders. Only files directly in the folder are moved. Your existing structure stays intact.
It never deletes. Files are moved, not removed. If a category looks wrong, everything is still there, one folder away.

Three lessons I'd pass on

Make the safe behaviour the default. A script that moves files should have to be talked into it. Dry-run-first is a design decision, not a feature — and it's the reason I'd trust this on a real Downloads folder.
Small scripts beat small apps. This is about 70 lines and has no dependencies. It doesn't need a GUI, a config file, or a scheduler to be useful.
Print what you're doing. Every move gets a line of output, and the run ends with a count. When a script touches your files, silence is a bug.

This is the second tool in my Python Automation Toolkit — the first scrapes a catalogue into a clean Excel report, and this one tidies the folder that report lands in. Next, I'll write about the project that taught me the most: a RAG-powered assistant that answers questions about Pakistani electricity bills.

Malik Ali Hassan — .NET & full-stack developer, final-year Software Engineering student. I build Python automation, AI assistants, and web apps.

I Built a Scraper That Turns 1,000 Book Listings Into a Clean Excel Report — Here's How

Malik Ali Hassan — Wed, 04 Nov 2026 06:18:53 +0000

Most "learn web scraping" tutorials stop at printing a few titles to the terminal. That never felt like a finished tool to me, so I built one that goes all the way: scrape a catalogue, clean the data, and hand over a formatted Excel report someone could actually use.

The stack is plain Python: requests, BeautifulSoup, pandas, and openpyxl. No frameworks, no paid APIs. The target is books.toscrape.com, a site built specifically for practising scraping — so everything here is on a public practice page, not a real store.

What you end up with

Running two scripts produces:

data/books_raw.csv — the raw scrape, one row per book
data/books_clean.csv — the same data, cleaned
data/books_clean.xlsx — a formatted Excel report: bold headers, filters, a frozen top row, and sensible column widths

The full run collects 1,000 books, and the cleaned report's average price comes out at £35.07.

Step 0: Setup

pip install requests beautifulsoup4 pandas openpyxl

Three files: scraper.py (collect), clean_export.py (clean + export), and a data/ folder for the outputs.

Step 1: Scrape every page, not just the first one

A catalogue scraper that only reads page 1 is a demo, not a tool. The real job is walking the pagination until there is no "next" link left. The core loop does exactly that:

def scrape(max_pages=None):
    all_books = []
    page = 1
    while True:
        url = CATALOGUE_URL.format(page)
        response = requests.get(url, headers=HEADERS, timeout=20)
        response.raise_for_status()
        response.encoding = "utf-8"
        books, has_next = parse_page(response.text, url)
        all_books.extend(books)
        if not has_next:
            break
        page += 1
        if max_pages and page > max_pages:
            break
        time.sleep(0.2)  # be polite to the server
    return all_books

Each page is parsed with one function that pulls five fields out of every book card:

def parse_page(html, page_url):
    soup = BeautifulSoup(html, "html.parser")
    books = []
    for article in soup.select("article.product_pod"):
        title = article.h3.a["title"].strip()
        price_text = article.select_one("p.price_color").get_text(strip=True)
        rating_word = article.select_one("p.star-rating")["class"][1]
        availability = article.select_one("p.instock").get_text(strip=True)
        rel_url = article.h3.a["href"]
        books.append({
            "title": title,
            "price": price_text,
            "rating": rating_word,
            "availability": availability,
            "url": urljoin(page_url, rel_url),
        })
    has_next = soup.select_one("li.next a") is not None
    return books, has_next

Three details worth calling out, because each one bit me or would have:

The £ encoding gotcha. This site doesn't declare its charset, so requests guesses Latin-1 and corrupts the £ sign. The pages are actually UTF-8, so one line — response.encoding = "utf-8" — fixes it before parsing. If your scraped prices ever look like Â£51.77, this is almost certainly why.
Be polite. A 0.2 second sleep between pages and an honest User-Agent (python-automation-toolkit/1.0 (learning project)) cost nothing and keep you from hammering someone else's server. Scraping fast is not a skill; scraping without getting blocked is.
Relative URLs. Book links on the page are relative, so urljoin(page_url, rel_url) turns them into full URLs you can actually click later.

Run it with python scraper.py (or --pages 5 for a quick test run), and you get data/books_raw.csv with 1,000 rows.

Step 2: Clean the data before anyone sees it

Raw scraped data is never report-ready. Prices are strings with currency symbols (£51.77), ratings are words (Three), and availability is a sentence fragment. The cleaning step turns all of that into typed, analysable data:

RATING_MAP = {"One": 1, "Two": 2, "Three": 3, "Four": 4, "Five": 5}

def clean(df):
    df = df.copy()
    # "£51.77" -> 51.77 (drop anything that is not a digit or a dot)
    df["price"] = df["price"].astype(str).str.replace(r"[^0-9.]", "", regex=True)
    df["price"] = pd.to_numeric(df["price"], errors="coerce")
    df = df.dropna(subset=["price"])
    # "Three" -> 3
    df["rating"] = df["rating"].map(RATING_MAP)
    # "In stock" -> True, anything else -> False
    df["in_stock"] = df["availability"].str.contains("In stock", na=False)
    df = df.drop(columns=["availability"])
    df = df.drop_duplicates(subset=["title", "url"])
    return df

The pattern here is worth stealing for any scrape: strip, convert with errors="coerce" (bad values become NaN instead of crashing the run), drop the rows that didn't convert, and drop duplicates on a sensible key — here, title + URL.

Step 3: Export an Excel file a human would enjoy opening

A CSV is fine for machines. If a person is going to read the report, formatting matters — and it's only a few lines with openpyxl:

def write_excel(df, path):
    with pd.ExcelWriter(path, engine="openpyxl") as writer:
        df.to_excel(writer, sheet_name="Books", index=False)
        sheet = writer.sheets["Books"]
        for cell in sheet[1]:
            cell.font = Font(bold=True)
        sheet.auto_filter.ref = sheet.dimensions
        sheet.freeze_panes = "A2"
        widths = {"title": 55, "price": 10, "rating": 10,
                  "in_stock": 10, "url": 60}
        for idx, col in enumerate(df.columns, start=1):
            sheet.column_dimensions[get_column_letter(idx)].width = (
                widths.get(col, 20)
            )

Bold headers, filters, a frozen top row, columns wide enough for the content. That's the difference between "here's a file" and "here's a report."

python clean_export.py also prints a short summary: book count, average price, how many are in stock, and the rating mix.

The result

Output	Contents
`books_raw.csv`	1,000 books, raw strings
`books_clean.csv`	1,000 books, typed and deduplicated
`books_clean.xlsx`	Same data, formatted and filterable

Average price across the catalogue: £35.07.

Three lessons I'd pass on

Scrape practice sites to learn. Real sites have terms of service, rate limits, and anti-bot measures. Learn the mechanics on a site built for it, and only scrape public pages with permission when real data is involved.
The pipeline is the project. Scraping is the easy third. Cleaning and presenting the data is where a script becomes a tool someone would pay for.
Small, polite, honest scripts beat clever ones. A 0.2 second delay and a real User-Agent never got anyone blocked; pretending to be a browser did.

The full code is in my Python Automation Toolkit project, and the same scrape → clean → report pattern works for any tabular listing: products, jobs, or prices. Next, I'll write about the other half of the toolkit — a file organiser that tidies a messy downloads folder without ever deleting anything by default.

Malik Ali Hassan — .NET & full-stack developer, final-year Software Engineering student. I build Python automation, AI assistants, and web apps.