Ahmed Khalid's Work | ContraWork by Ahmed Khalid
Ahmed Khalid

Ahmed Khalid

AI/ML & MLOps Engineer building scalable full-stack systems

New to Contra

Ahmed is building their profile!

Cover image for Problem Statement
The Iris dataset is
Problem Statement The Iris dataset is a teaching staple, but nobody builds it like it would actually run in production. The goal was to demonstrate what a fully operationalised ML system looks like — CI/CD, drift detection, hot-swap model updates, explainability — using a problem simple enough to keep the focus on the infrastructure, not the data science. Solution & Approach Implemented CI/CD/CT/CM (Continuous Training and Monitoring) using GitHub Actions. KS tests and PSI detect distribution drift on incoming data; a new model is auto-trained and hot-swapped via a rolling update if drift is confirmed. Every prediction returns a SHAP explanation. The test suite covers 115 tests at 84% coverage across FastAPI endpoints, ML pipeline stages, and data validation logic. Decoupled React frontend and FastAPI backend are deployed independently on Vercel and Google Cloud Run. Key Highlights - Full CI/CD/CT/CM pipeline with GitHub Actions orchestration - KS test + PSI drift detection with automated hot-swap model updates - SHAP explanation returned with every prediction - 115 tests at 84% coverage across API, pipeline, and data validation layers - Zero-downtime rolling updates on model promotion Try the live app : https://iris-classification-system-ml-ops.vercel.app/
0
13
Cover image for Problem Statement
Crypto traders lack interpretable,
Problem Statement Crypto traders lack interpretable, short-horizon price signals that combine market sentiment with price momentum. Most sentiment tools are disconnected from live trading data and have no production ML lifecycle behind them. Solution & Approach Built a production-grade ML system that fetches live Bitcoin price data and news every 15 minutes via GitHub Actions, engineers 40+ features combining VADER and FinBERT sentiment scores with price and temporal signals, and trains/evaluates an ensemble of XGBoost, LightGBM, Random Forest, and Logistic Regression models. PSI drift detection gates model promotion; rollback restores the last stable model automatically. A Next.js frontend visualises live predictions with confidence intervals. Key Highlights 15-minute fully automated pipeline via GitHub Actions Dual sentiment engine: VADER (speed) + FinBERT (accuracy) compared head-to-head 40+ engineered features combining sentiment, price, and temporal signals PSI drift detection with automatic rollback to last stable model Sub-200ms inference latency on Google Cloud Run Note : This project has backend that is deployed on free-tier service which may cause the backend to be suspended GitHub Link : https://github.com/AhmedIsmailKhalid/Enhanced-News-Sentiment-Analysis-for-Bitcoin-Price-Prediction
1
0
42
Cover image for Problem Statement
Wedding planning is fragmented.
Problem Statement Wedding planning is fragmented. Couples spend hours across dozens of websites researching vendors with no central place to browse, compare, save, and reach out to multiple vendor types at once. Vendors lack an affordable platform to showcase their work and receive qualified inquiries directly from engaged couples. Solution & Approach Built a full-stack wedding vendor marketplace using Next.js 14 App Router with React Server Components — all data-fetching pages render server-side with zero client-side loading spinners on first paint. The platform features two authenticated portals (couple and vendor) and an admin approval workflow. Vendor photos upload directly from the browser to Cloudinary, bypassing the server entirely. The inquiry system supports multi-turn threaded conversations with a senderRole field distinguishing vendor replies from couple follow-ups. Route protection is enforced at three independent layers: Proxy Middleware (edge), Server Component session check, and API route ownership validation. Key Highlights - Next.js 14 App Router with React Server Components — zero client-side loading on first paint - Three-layer auth: Proxy Middleware + Server Component check + API ownership validation - Direct Cloudinary upload pipeline — images bypass the server, only metadata stored in PostgreSQL - Multi-turn inquiry conversation system with senderRole field for threaded vendor/couple dialogue - Admin approval workflow — listings hidden until approved, with full vendor review panel - Full-text vendor search with category, location, and price range filters - 3 user roles (Couple, Vendor, Admin), 7 vendor categories, live demo accounts on login page
0
21
Cover image for Problem Statement
SaaS applications need real-time
Problem Statement SaaS applications need real-time notification systems, but building one correctly is deceptively complex. Polling is unreliable, SSE is one-directional, and most teams bolt on a third-party widget rather than engineering the connection lifecycle, auth, preferences, and delivery guarantees properly from scratch. Solution & Approach Built a production-grade WebSocket notification system using Socket.io (http://Socket.io) with per-user rooms authenticated at the handshake level via JWT. The backend is a Node.js + Express + Prisma monorepo connected to NeonDB (serverless Postgres). Notifications are grouped by date, filterable by type (Mentions, Comments, Team Activity, System Alerts, Assignments), and preferences are persisted per-user per-category. A built-in simulator fires live demo events so reviewers can experience real-time delivery without any setup. Deployed on Google Cloud Run (backend) and Vercel (frontend). Key Highlights WebSocket rooms authenticated at handshake via JWT — no unauthenticated connections possible 7-filter notification center: All, Unread, Mention, Comment, Team, System, Assignment Per-user per-category preferences with live inApp and email toggles Built-in notification simulator for live demo without reviewer setup Auto-reconnect with exponential backoff on network drop
2
0
76
Cover image for Problem Statement
Small service businesses such
Problem Statement Small service businesses such as salons, studios, clinics can get stuck choosing between Calendly (too generic, no customisation) and Acuity (expensive, over-featured). They need a branded, per-stylist booking experience with real availability logic, not a white-label widget bolted onto their site. Solution & Approach Built a production-deployed, end-to-end TypeScript monorepo with shared Zod schemas across frontend and backend. The 5-step booking wizard guides clients through service → stylist → date/time → details → confirmation. Availability is computed per stylist with double-booking prevention using database-level transaction locking. A JWT-secured admin dashboard allows staff to manage bookings, services, and schedules. Transactional emails fire-and-forget via a queue so the booking response is never blocked on email delivery. Key Highlights 5-step guided booking wizard with per-stylist real availability engine Database-level transaction locking prevents double-bookings under concurrent load JWT-secured admin dashboard: bookings, services, and staff management Fire-and-forget transactional email — booking response never blocked on delivery 100% TypeScript monorepo with shared Zod validation across frontend and backend
1
0
34