Syed Hassan Ali Bukhari

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.

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.

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.