Shaik Asad Ahmed

Full-Stack Developer

G Pullaiah College of Engineering and Technologyfull_time, internship, freelance

Open to roles

Problem SolvingCommunicationAgile/ScrumProject Management

Student Expense Tracker (CLI + Web) — Budget-Aware Spending Tool for College Students

College students frequently make small daily payments (UPI, canteen, travel, recharges) but lack a simple way to track them consistently. Most existing tools require apps, internet, or complex interfaces, which leads to irregular usage. In informal conversations with peers, a common pattern emerged: students either rely on memory or scattered notes, making it hard to understand total spending or identify where money is going. The gap: a lightweight, no-dependency tool that works instantly from the command line and encourages consistent daily tracking without friction. Process I focused on reducing friction rather than adding features. The goal was to make expense tracking as quick as possible from the terminal. I started with a basic list-based approach to store expenses and built core functions (add, view, total, category analysis). Initially, I considered adding more categories and filters, but this made the flow slower and less intuitive, so I kept categories minimal (food, travel, recharge, other). To improve usability, I added: * Preloaded sample data so output is visible immediately * JSON persistence so data is not lost between runs * Input validation to prevent crashes For the bonus feature, I implemented a monthly budget system. Instead of just showing a limit, I added a two-level warning: * 80% usage → early alert * 100%+ → over-budget warning Results The final program successfully performs all required tasks without errors, including handling invalid inputs (wrong date format, negative amounts, unknown categories). In testing, the system correctly calculated totals (₹879) and triggered budget warnings when exceeding the set limit (₹500), demonstrating real-world usability. The tool reduces manual tracking effort to a simple CLI interaction and provides immediate insights such as total spending and highest category. Overall, the solution is reliable, and requires no external dependencies, making it practical for everyday student use. Reflection With more time, I would add time-based filtering (weekly/monthly views) and a simple visualization (bar chart) to help users compare spending across categories. I would also improve the user experience by adding edit/delete options and possibly a lightweight GUI version for users less comfortable with the command line. Additionally, I would explore storing data in a more structured format to support long-term usage and scalability.

4 media files · gilded-melomakarona-6140ba.netlify.appView

Queue Cure '26 — Real-Time Clinic Queue Management

76% of India's 1.5 million clinics still run on paper token slips and shouting. Patients wait 2–3 hours with zero visibility into when they'll be called. Receptionists manage everything from memory — adding patients, tracking who's next, estimating wait times. There is no dashboard for doctors, no data on actual wait times, and no way for patients to know their position without physically being present and alert at all times. The result: anxiety, crowding, missed calls, and zero data to improve the system. Process I started by mapping two user journeys, the receptionist and the waiting patient and identifying the single most painful moment for each. For the receptionist it's managing state in their head. For the patient it's not knowing when they'll be called. I chose Socket.IO over HTTP polling because real-time push eliminates the 2-5 second lag and wasted requests of polling. I deliberately put all queue state on the server only clients emit intents, the server decides the outcome and broadcasts to everyone simultaneously. This eliminates any possibility of the receptionist screen and patient screen showing different data. I added MongoDB not just for persistence but for analytics storing actual wait times per patient lets the clinic measure and improve. I handled the fallback gracefully Results Live sync working across all screens in under 50ms with zero page refresh. MongoDB Atlas storing complete patient history — token issued time, called time, actual wait duration, skip status. Analytics dashboard showing daily completion rate, average actual wait, and per-patient history. Graceful fallback to memory-only mode when DB is unavailable. All 7 edge cases handled with server-side guards and error callbacks. The system correctly handles multiple receptionists operating simultaneously with no state drift. Reflection I would add a QR code on each token slip so patients can scan it and auto-track their position on their phone without manually entering a token number. I'd also add SMS/WhatsApp notification when a patient is 2 tokens away — so they don't need to stare at the screen. With more time I'd build a doctor dashboard showing who's next before calling, and hour-by-hour analytics to identify peak clinic hours for better staffing.

4 media files · queue-cure-26-1-ao05.onrender.comView

This is Shaik’s work on Wooble.

Build a profile that shows what you can do — and share it anywhere.

Build yours