Everything from Android apps in production to coursework and side experiments.
Offline, privacy focused Android expense tracker. No accounts, no cloud sync, no ads, all data stored locally.
Motivation
Built out of a real frustration: pocket money disappearing by the 20th of every month with no idea where it went. Wanted something simple, private, and reliable.
Features
Monthly or weekly budget cycles with a live progress bar. Dashboard shows spent, remaining, and average daily spend. Spending calendar color-codes each day based on your daily budget. Green means under, red means over. Settlements ledger tracks money owed to and from others, separate from your budget. Full history with filters by month, week, or day, sortable and searchable. Backup and restore, light and dark themes, and edit support for existing entries.
Architecture
Built with Kotlin and Room DB for local storage. No internet permission, no accounts, no cloud sync, everything stays on your device. The backup feature exports data as a file to a location you choose.
Challenges
The biggest hurdle was v2.0.0: Google Play Console flagged deprecated APIs, so the entire codebase was converted from Java to Kotlin, and the database was migrated from JSON files to Room DB, all in one release.
Lessons
Staying current with Android APIs is non-negotiable. Data migration needs to be handled carefully to avoid losing user data. Also learned that a clean, focused app with no tracking actually stands out in a crowded market.
A university companion app for tracking subjects, GPA, and study tasks, with a dashboard for what's due and a custom accent color picker to make it yours.
Motivation
Built out of a real problem: tracking assignments and quizzes through WhatsApp messages, diary entries, and scattered notes was not working. Things were getting missed, deadlines forgotten, and GPA calculations done by hand on paper. Gradix exists to put all of that in one place, know what is coming, get reminded before it arrives, and always know exactly where you stand academically.
Features
• Subjects built out of Parts (Theory, Lab, Clinical, or whatever your program uses) and Components inside each Part, with custom names, weightage, and whether they happen once or repeat
• Dashboard showing Upcoming and Ongoing Work alongside Study Tasks
• Subjects tab listing every subject with credit hours, percentage, and GPA
• Progress tab breaking each subject down by its own components in a pie chart, plus overall semester GPA
• Tools tab with an Attendance Tracker (tracks classes attended and missed, and how many more you can afford to miss), Subject, Semester, and CGPA calculators, and an Improvement Effect Calculator to see what raising one subject does to your semester and overall CGPA
• Home screen widgets for upcoming assessments and pending study tasks
• Custom accent color picker with eight named options, each with its own personality, blue stays the default
• Full backup and restore to a JSON file
• Notification reminders a day before and the day of a deadline
• One-time onboarding guides for Dashboard, Subjects, and Progress
Architecture
Built with Kotlin, Material3, and Room DB for local storage. No accounts, no cloud, everything stays on the device.
Challenges
Gradix originally only worked for COMSATS, with Theory Mid, Theory Final, Lab Assignment, Lab Mid, Lab Final, and Quizzes hardcoded straight into the app. Anyone on a different grading structure, or at a different university, just could not use it properly. Version 2.0.0 tore that out completely and rebuilt subjects around user defined Parts and Components instead, so it now works for any HEC recognized BS program.
The codebase also had to be migrated entirely from Java to Kotlin at one point, a full rewrite done on its own rather than alongside any feature work.
Lessons
Hardcoding one university's structure into the app from the start limited who could actually use it, flexibility should have been the foundation, not something bolted on later. Also learned that small things like remembering a user's default averaging method or accent color choice go a long way in making an app feel personal rather than generic.
Console based epidemic contact tracing simulator for a 3rd semester DSA course. Models an outbreak as a graph and builds seven data structures from scratch, stack, queue, heap, AVL tree, hashmap, graph, plus Dijkstra and Prim's, for risk scoring, transmission tracing, and containment.
Motivation
Inspired by real-world epidemic response challenges highlighted during COVID-19. Wanted to understand how contact tracing, risk prioritization, and containment decisions work under the hood by building the entire system from scratch.
Features
Load patient and contact data from CSV files. Register new patients with automatic risk scoring (7 criteria, max 130 points). View per-patient investigation logs (stack events). Simulate outbreak spread wave by wave from any source (BFS). Trace transmission chains between patients (Dijkstra). Find minimum containment networks for active clusters (Prim's). Filter cases by day, area code, or date range. Geographic hotspot detection via area code hashmap.
Architecture
Eight data structures implemented from scratch using linked lists, no STL containers. Stack for investigation logs, Queue for case pipeline, Heap for risk priority, AVL Tree for date-indexed records, HashMap for ID/area lookups, Graph for contact networks, Dijkstra for transmission paths, and Prim's for containment. All structures were built iteratively as requirements emerged.
Challenges
Building every data structure from scratch meant constant revisiting and refinement. Each new feature exposed edge cases that required going back to foundational code. The structures weren't plug-and-play; they had to adapt to real use cases.
Lessons
Data structures aren't just theory you memorize for exams; they're the foundation of real systems. Implementing AVL trees and heaps yourself makes clear why certain operations are O(log n) and why edge cases like tree rotations matter. Planning architecture upfront saves time, because changes in one structure ripple through the entire system.
Crime record management web app supporting both Oracle XE and MongoDB through one interface. Role based access, FIR and case tracking, evidence handling, and a custom query editor for either database.
Motivation
Built as a semester project for the Database Systems course. The goal was to build the same system using two fundamentally different databases and make the experience completely seamless for the user.
Features
Role-based access control with admin and officer roles. Criminal record management, FIR and case tracking, evidence handling, victim registry, and officer management. Custom query runner allows executing raw SQL (Oracle) or MongoDB queries directly through the web interface. Switch between databases with a single button; the interface feels identical regardless of which database is running underneath.
Architecture
Node.js + Express backend with a unified abstraction layer that handles the differences between SQL and NoSQL behind the scenes. Oracle XE uses structured tables with joins, MongoDB uses document collections, but the user never notices the difference.
Challenges
Building a unified abstraction layer that works consistently across SQL and NoSQL was the hardest part. CRUD operations and data modeling are fundamentally different under the hood. Oracle requires careful schema design, while MongoDB is more flexible but comes with its own tradeoffs.
Lessons
Learned how to abstract database logic behind a unified interface. Gained practical experience with both relational and document-based databases. Understood the tradeoffs: SQL gives you structure and joins, NoSQL gives you flexibility and speed; both have their place.
Hospital management system in Java backed by Oracle Database, with both a console version and a Swing GUI. Handles doctor, patient, and medicine records plus a custom SQL query runner.
Motivation
Built as a stripped-down version of TRACK to practice Java and Oracle Database integration after a midterm exam. It was a learning exercise to prepare for the larger Database Systems project.
Features
Both console and GUI versions. Doctor, patient, and medicine management with full CRUD operations. Custom SQL query runner for executing raw queries directly from both interfaces. Oracle Database connectivity using JDBC. Interactive forms and tables in the Swing version.
Architecture
Two separate implementations, console (focus on backend logic) and Swing GUI (visual interface), sharing the same database backend. JDBC handles all database communication.
Challenges
Getting JDBC to work reliably with Oracle Database was tricky. Managing database connections properly and handling SQL exceptions gracefully across both implementations required careful design.
Lessons
Learned practical JDBC usage and Oracle Database integration. Reinforced the importance of separating database logic from business logic. Also learned the differences between console and GUI application design. Console forces you to think about flow, GUI forces you to think about user experience.
Browser based tool that generates printable networking cards with QR codes linking to social profiles, built after noticing people hand designing these at a hackathon.
Motivation
Noticed people at a hackathon manually designing networking cards in Word or Canva, repetitive and time-consuming. The concept was simple: scan a QR code and instantly access someone's profile. Decided to automate the whole thing.
Features
Generate networking cards with QR codes; create two cards for different social platforms. Customize QR code colors. Preview cards instantly. Print or save as PDF with a print-ready A4 layout. Supports GitHub, LinkedIn, Twitter, Instagram, YouTube, and custom links. Fully client-side with no backend required.
Architecture
Single HTML file with embedded CSS and JavaScript. Uses QRCode.js library for QR generation. Everything runs client-side; no data is sent anywhere.
Challenges
Getting the print layout exactly right for A4 paper was tricky, since browser print handling varies across browsers. Had to use specific print CSS rules to ensure consistent output.
Lessons
Learned about client-side QR code generation using QRCode.js, print CSS for consistent output across browsers, and how to build a fully self-contained single-page application without any backend dependencies.
Java based student result management system with console and Swing GUI versions.
Motivation
Started as a required student result management system for a course, but extended it into a more functional and robust university portal. The challenge was to do it all within existing classes, no new classes allowed.
Features
Student result management with console and GUI versions. Extended beyond basic result management to include additional university management features, all within the existing class structure.
Architecture
Two separate implementations, console (focus on backend) and Swing GUI (visual interface), sharing the same logic. Everything was carefully organized within existing classes without adding new ones.
Challenges
Working within the constraint of not adding extra classes while still extending functionality required creative solutions. Had to carefully plan method placement and class responsibilities to keep the code organized.
Lessons
Learned how to work within tight constraints and still deliver a functional, extended product. Reinforced the importance of clean class design and method organization. Also gained practical experience with both console and GUI versions of the same application.
First semester Python project. Console app for submitting and tracking hostel complaints by category, with an admin panel for reviewing and resolving them.
Motivation
First semester Python project. Built to learn Python fundamentals through a practical application: a console-based hostel complaint management system.
Features
Submit complaints with categories (Food, Water, Electricity, Internet, Maintenance, Others). Automatic serial numbers for each complaint. Persistent file-based storage using plain text files. Admin panel with password protection to view, update, and resolve complaints. Structured folder system for organizing complaint data.
Architecture
Console-based application using Python's file handling for persistent storage. Complaints stored as text files in a structured Data/complaints folder. Uses complaint_index.txt for active complaints and resolved_complaints.txt for resolved ones.
Challenges
Implementing persistent storage with plain text files was the main challenge; this was the first time working with file I/O. Had to design a structured folder system for complaints while keeping it simple.
Lessons
Learned Python fundamentals: functions for modular programming, file handling for data persistence, building a menu-driven console application, and creating a basic password-protected admin system. Also learned that simple file-based storage can be surprisingly effective for small applications.
First semester Java project. Console app for booking and cancelling flight tickets with an admin menu for managing flights.
Motivation
First semester Java project. Built to learn Java fundamentals through a practical application: a console-based flight reservation system.
Features
View all available flights with details (ID, Source, destination, price, seats left). Book a ticket and generate a ticket file. Cancel a booked ticket. Admin menu to add or remove flights. Persistent storage using text files (flights.txt and bookings.txt). Seat layout display (O = available, X = booked).
Architecture
Console-based application using parallel static arrays for in-memory state. Seat map is a 3D array seats[flightIndex][row][col]; rows map to A-E, columns map to 1-4. All data persisted through plain text CSV files in a Data/ folder. Uses temp-file swap pattern for safe file updates. Ticket files are generated with unique names to avoid collisions.
Challenges
Handling file persistence properly was the main challenge; you can't delete a line from a text file in place, so the temp-file swap pattern was essential. Also had to manage input validation for seat codes, duplicate IDs, and edge cases like missing files.
Lessons
Learned Java syntax, loops, conditionals, file handling, 3D arrays, and basic CRUD operations with admin functionality. Also learned the temp-file swap pattern for safe file modifications, a technique that's useful in many contexts.
A Flappy Bird style game built in Java Swing to learn GUI programming, game loops, collision detection, and audio playback.
Motivation
Built during a tough midterm exam period in 2nd semester as a way to cheer up and reset. The game is a parody featuring the "Sparrow", a viral Pakistani TikToker known for saying "Ouch Ouch Ouch." Pure fun, but also a learning exercise.
Features
Press SPACE to make the sparrow flap. Avoid pipes; each obstacle passed increases your score. Background music and game-over sound. Press SPACE to restart after game over. Custom graphics (sparrow, pipes, background, game over screens) and audio files.
Architecture
Java Swing GUI application with a game loop using Timer. Uses Java AWT for graphics and event handling, and Java Sound API for audio playback. Keyboard input handling for flapping and restarting.
Challenges
Learning Java Swing and GUI development from scratch was the main challenge. Implementing the game loop with Timer, handling keyboard input, collision detection with pipes, and loading images and audio correctly, all new territory.
Lessons
Learned Java Swing GUI development, game loop implementation using Timer, keyboard input handling, collision detection, image and audio loading, and basic Java project structuring. Also learned that building something fun can be a great way to reset during stressful times, and you learn just as much as you would from a "serious" project.
Terminal program in Java and OpenCV that converts video into ASCII art synced with audio, built to practice multithreading.
Motivation
Personal learning project to practice multithreading, file handling, and OpenCV integration. Wanted to explore how to convert video frames to ASCII art synchronized with audio playback through the terminal.
Features
Converts video frames to ASCII characters based on brightness levels; darker pixels become denser characters ('@' or '#'), lighter pixels become sparser characters ('.' or space). Plays synchronized audio and video in real time. Uses OpenCV for video frame extraction. Fully Linux-ready via a shell script.
Architecture
Java application using OpenCV for video processing. Uses a dedicated thread for audio playback and another for video frame rendering, synchronized using timing control. Frames are mapped to ASCII characters based on brightness levels.
Challenges
Synchronizing audio and video playback across separate threads was the hardest part. Also had to ensure the OpenCV Java bindings worked correctly and that the terminal output refreshed fast enough for a smooth experience.
Lessons
Learned multithreading and synchronization in Java, OpenCV Java bindings for video processing, audio playback using javax.sound.sampled, and how to structure a Linux-ready Java project with a shell script. Also learned about the balance between performance and simplicity in terminal-based applications.