Systems Delivered

Systems With Clear Engineering Trade-offs

Production systems, public products, engineering labs, and prototypes are classified explicitly. Employer and client systems remain anonymized.

Engineering Lab

Browser-Based Proof-of-Work Simulation & Validation Lab

View Project

Engineering Scope

Interactive blockchain simulation, mining workflow visualization, deterministic validation, benchmark reporting, persistence, and JavaScript/WebAssembly execution paths.

Problem Statement

Blockchain concepts are often explained abstractly, making it difficult to show wallets, pending transactions, mining rewards, Proof-of-Work difficulty, validation, and tamper detection without connecting to real cryptocurrency networks.

Architecture Overview

React and Vite browser application with Zustand state management, localStorage persistence, Recharts benchmark visualization, crypto-js SHA-256 hashing, and an optional C++ WebAssembly mining engine with JavaScript fallback.

Data Flow Explanation

Users create simulated wallets, submit validated transactions into a pending pool, mine pending transactions plus a SYSTEM reward into blocks, and inspect the resulting chain through explorer, validation, benchmark, and tamper-detection flows.

Engineering Decisions

Core blockchain behavior was kept in dedicated modules for blocks, hashes, transactions, wallets, mining, validation, and simulation import/export. Balances are derived from confirmed chain data instead of trusted as mutable wallet fields.

Scale & Reliability Considerations

Mining runs in bounded batches and yields control back to the browser so the interface remains responsive. Difficulty is intentionally capped from 1 to 5, and the WebAssembly miner is optional so the JavaScript fallback keeps the app portable.

Outcome

Produced an interactive engineering lab that makes Proof-of-Work, nonce search, mining rewards, chain validation, tamper detection, and benchmark behavior visible without mining real cryptocurrency.

MVP / SaaS Foundation

Billora SaaS Invoicing & Billing Platform

View Project

Engineering Scope

Authenticated SaaS invoicing workflows, organization and team management, business profiles, customers, invoice items, manual payments, payment status tracking, PDF generation, audit logs, background jobs, and dashboard summaries.

Problem Statement

Small businesses often manage invoices through spreadsheets, manually edited PDFs, message threads, and disconnected payment notes. That creates duplicate records, unclear payment state, inconsistent customer data, and weak ownership across teams.

Architecture Overview

Next.js and TypeScript web app with authenticated dashboard, customer, invoice, settings, registration, and invite flows. A modular NestJS API uses Prisma and PostgreSQL for users, organizations, members, invites, businesses, customers, invoices, invoice items, payments, and audit logs. Redis-backed jobs support invoice PDF generation and email job orchestration.

Data Flow Explanation

An authenticated user selects a business and customer, enters invoice items, tax, discount, issue date, due date, and notes, then submits the invoice to the API. The backend validates the DTO, checks organization and business access, calculates totals, writes invoice data through Prisma transactions, and records audit events. Manual payments update payment records, paid totals, invoice status, and generated-document freshness.

Engineering Decisions

NestJS was selected for modular backend boundaries, guards, dependency injection, and DTO validation. Prisma and PostgreSQL fit the relational billing model, while Next.js provides a practical TypeScript web foundation. Redis-backed jobs keep document and email workflows outside the request path. Real payment gateways, production email delivery, and the planned Flutter mobile app were deferred so the core SaaS ownership and billing model could be hardened first.

Scale & Reliability Considerations

Organization-level ownership prepares the platform for teams and multi-business workspaces. Pagination and filtering support customers, invoices, payments, and audit logs. Transactions protect invoice creation and payment recording, while background jobs prepare PDF and email workflows for heavier workloads.

Outcome

Built a working SaaS invoicing MVP foundation with authentication, organization membership, business profiles, customer management, invoice creation, calculated totals, manual payment tracking, generated invoice documents, audit logs, dashboard summaries, and initial API/web test coverage.

Functional MVP

Itinerary Orchestration & Cost Modeling Platform

View Project

Engineering Scope

Destination discovery, personalized multi-day itineraries, regional multi-currency pricing, package reservations, custom-trip registrations, and authenticated travel operations.

Problem Statement

Travel planning information for Pakistan is fragmented across destination websites and manual booking channels. The platform needed to unite research, itinerary creation, cost estimation, package discovery, and registration in one coherent experience.

Architecture Overview

Next.js 14, React, TypeScript, and Tailwind CSS power the responsive frontend. A modular NestJS REST API uses Prisma and PostgreSQL for destinations, itinerary days, packages, bookings, custom-trip registrations, and persistent pricing snapshots, with token-based authentication protecting admin operations.

Data Flow Explanation

Budget, duration, and traveler interests feed an itinerary engine that selects destinations and distributes days across the route. A centralized pricing service applies traveler-market rates, currency conversion, service fees, and security costs before persisting the itinerary and its pricing snapshot. Package and custom-trip submissions then enter admin-managed operational workflows.

Engineering Decisions

Itinerary composition, destination content, and pricing rules were separated into explicit domains. Price and exchange-rate inputs are snapshotted so historical totals remain operationally accurate, while booking creation and cancellation reconcile package seats. DTO validation, structured database-aware errors, and references such as PV-ITN-XXXXXX and PV-CTR-XXXXXX make workflows traceable.

Scale & Reliability Considerations

Relational models and a centralized pricing boundary support additional destinations, traveler markets, currencies, and fee rules without duplicating calculations across screens. The MVP currently uses admin authentication and local file-backed media workflows; customer accounts, RBAC, payment-gateway integration, and production cloud image storage remain future enhancements.

Outcome

Delivered a functional full-stack MVP that combines Pakistan destination discovery, shareable itinerary generation, multi-currency cost modeling, package reservations, custom-trip intake, and authenticated operational management.

Production System

Commerce Catalog & Order Processing Platform

View Project

Engineering Scope

Mobile catalog discovery, promotional offers, cart state, transactional order capture, order tracking, caching, and release automation.

Problem Statement

High-volume catalog discovery, cart behavior, flash offers, order tracking, and mobile-first browsing needed to remain responsive under promotional traffic.

Architecture Overview

Flutter mobile client, Node.js API services, PostgreSQL product and order data, Redis caching, object storage for media, Dockerized deployment on AWS.

Data Flow Explanation

The app reads catalog snapshots through paginated APIs, resolves pricing and availability through backend services, writes cart and order events through transactional endpoints, and receives order updates through push and polling fallbacks.

Engineering Decisions

Flutter supported consistent UI performance across devices. Node.js fit high-concurrency API workloads. Redis reduced repeated catalog and offer reads, while PostgreSQL kept transactional order integrity.

Scale & Reliability Considerations

Catalog endpoints were cached by segment, media was moved behind CDN-ready storage, order writes were isolated from browsing traffic, and slow queries were profiled around filters and promotions.

Outcome

Improved browsing responsiveness through profiling and architecture changes, while repeatable build and deployment pipelines reduced release overhead.

Public Product

Schema-Driven Modular Content Management System

View Project

Engineering Scope

Reusable content sections, structured page configuration, focused admin workflows, backend rendering, and shared-hosting-aware deployment.

Problem Statement

Small professional websites needed dynamic page management, reusable content sections, a simple admin workflow, and deployment compatibility with constrained hosting environments.

Architecture Overview

Laravel application with JSON-based page sections, PHP backend rendering, admin-managed content, and shared-hosting-aware deployment assumptions.

Data Flow Explanation

Admin users manage structured page sections, the CMS stores those sections as page configuration, and the frontend renders reusable blocks from the saved content model.

Engineering Decisions

Laravel provided routing, persistence, and admin workflow primitives quickly. JSON section configuration kept the CMS flexible without overbuilding a large page-builder system.

Scale & Reliability Considerations

Reusable section definitions reduce page-specific code, while the constrained deployment model keeps the system practical for low-cost hosting and small business sites.

Outcome

Produced a reusable CMS foundation for modular business websites with practical admin controls and deployment-aware architecture.

Production System

Real-Time Field Operations & Event Synchronization System

View Project

Engineering Scope

Field activity capture, operational state transitions, live event delivery, alerting, reconnection, and state reconciliation for intermittent networks.

Problem Statement

Operational teams required live visibility into distributed field activity, status transitions, alerts, and mobile updates across unstable network conditions.

Architecture Overview

React Native mobile surface, Node.js backend, WebSocket channels, PostgreSQL persistence, Redis pub/sub, and Docker-based cloud deployment.

Data Flow Explanation

Field events are persisted through APIs, broadcast through real-time channels, acknowledged by clients, and reconciled through periodic state refreshes when connectivity drops.

Engineering Decisions

WebSockets handled low-latency updates while REST endpoints preserved deterministic recovery. Redis decoupled event fan-out from database writes.

Scale & Reliability Considerations

Event streams were partitioned by operational scope, reconnection logic was hardened, and hot status reads were cached to reduce database pressure.

Outcome

Delivered real-time operational visibility with resilient fallback behavior for intermittent mobile networks.

Production System

Role-Based Service Marketplace & Booking Platform

View Project

Engineering Scope

Customer, provider, and admin workflows covering service discovery, booking, payment coordination, notifications, and operational control.

Problem Statement

A marketplace needed role-based workflows, service discovery, booking logic, payment coordination, and admin operations without collapsing into one large application layer.

Architecture Overview

Flutter mobile app, Django backend, PostgreSQL relational model, role-based APIs, admin dashboards, Docker deployment, and CI/CD release flow.

Data Flow Explanation

Users discover services, submit requests, update booking states, and trigger notifications through API workflows guarded by role and state transition rules.

Engineering Decisions

Django accelerated secure admin and relational workflow development. Flutter enabled shared mobile delivery while repository boundaries kept feature logic isolated.

Scale & Reliability Considerations

Service search and booking queries were indexed, admin operations were separated from user-facing paths, and deployment automation reduced manual release work.

Outcome

Supported marketplace operations across customer, provider, and admin roles with a maintainable SaaS foundation.

Production System

Telemetry Ingestion, Alerting & Monitoring Platform

View Project

Engineering Scope

Telemetry ingestion, event normalization, dashboard summaries, alert evaluation, cached operational reads, and mobile visibility.

Problem Statement

Teams needed reliable mobile visibility into metrics, alerts, and device or service state without overloading the backend with repeated refresh traffic.

Architecture Overview

Flutter client, Node.js APIs, event-oriented telemetry storage, PostgreSQL metadata, Redis cache, alert workers, and cloud services.

Data Flow Explanation

Telemetry enters ingestion endpoints, is normalized into event records, summarized for dashboards, and pushed to mobile clients through alert channels.

Engineering Decisions

The architecture separated ingestion, summary reads, and notification delivery so spikes in telemetry would not block dashboard usage.

Scale & Reliability Considerations

Aggregated views reduced raw event scans, caches protected common dashboard queries, and background workers handled alert evaluation.

Outcome

Created a stable monitoring surface with clearer alert delivery and reduced redundant polling from mobile clients.

Engineering Lab

Observability & Autoscaling Research Platform

View Project

Engineering Scope

Microservice instrumentation, load generation, metrics collection, dashboard analysis, baseline capacity testing, and autoscaling research.

Problem Statement

A microservices environment needed baseline observability, load testing, and a research path toward intelligent scaling decisions.

Architecture Overview

Python-based experimental services with Prometheus metrics collection, Grafana dashboards, Locust load testing, and a foundation for RL-based autoscaling research.

Data Flow Explanation

Services expose runtime metrics, Prometheus collects system behavior, Grafana visualizes pressure points, and Locust generates repeatable load patterns for scaling experiments.

Engineering Decisions

The experiment separates workload generation, telemetry capture, dashboarding, and scaling research so each part can be measured and changed independently.

Scale & Reliability Considerations

Baseline load profiles and metrics create the feedback loop needed for future autoscaling policy work and capacity experiments.

Outcome

Established an engineering lab for monitoring, load behavior, and intelligent scaling research.

Production System

Geospatial Tracking & Route Projection System

View Project

Engineering Scope

Location capture, GPS validation, trip-state processing, route projections, rider/admin views, throttling, and intermittent-network recovery.

Problem Statement

Operational users needed location updates, trip or task state, route visibility, and recovery from inconsistent GPS and network availability.

Architecture Overview

Cross-platform mobile clients, Node.js APIs, geospatial data in PostgreSQL, background location processing, and cloud deployment.

Data Flow Explanation

Driver location updates are validated, persisted, and projected into route status views consumed by rider and admin clients.

Engineering Decisions

Location writes were kept lightweight. Route projections were separated from raw location events to make client reads predictable.

Scale & Reliability Considerations

GPS updates were throttled, route views were cached, and background workers handled cleanup and trip state transitions.

Outcome

Delivered practical real-time tracking with controlled write volume and predictable mobile map behavior.

Production System

Event Registration & Attendee Operations System

View Project

Engineering Scope

Registration, attendee records, schedule updates, notifications, transactional capacity checks, and administrative event operations.

Problem Statement

Event teams needed registration, attendee operations, schedule updates, notifications, and admin workflows across mobile and backend surfaces.

Architecture Overview

Flutter mobile app, Django APIs, PostgreSQL, admin console, notification services, and CI/CD deployment.

Data Flow Explanation

Attendee actions flow through authenticated APIs, update event records, and trigger notifications or admin-visible state changes.

Engineering Decisions

Django offered strong admin primitives and relational integrity, while the mobile app kept event workflows modular and reusable.

Scale & Reliability Considerations

High-read event data was cached, registration paths were protected with transactional checks, and deployment automation reduced release friction.

Outcome

Enabled reliable event operations with mobile-first access and structured administrative control.

Production System

Occupancy, Billing & Residential Operations Platform

View Project

Engineering Scope

Resident records, room occupancy, billing support, service requests, role-based administration, and operational reporting.

Problem Statement

Residential operations required occupancy tracking, billing support, resident records, request handling, and admin controls in a reliable system.

Architecture Overview

Mobile and web operational interfaces, Django backend, PostgreSQL database, role-based access, reporting views, and Dockerized deployment.

Data Flow Explanation

Resident and room records are managed through authenticated workflows, operational requests move through status transitions, and reporting views summarize occupancy and activity.

Engineering Decisions

A relational backend fit the operational domain. Clear permission boundaries prevented admin, staff, and resident workflows from mixing.

Scale & Reliability Considerations

Indexed occupancy and billing queries, modular workflow services, and repeatable deployment helped the system remain maintainable as records grew.

Outcome

Delivered structured hostel operations with clearer data ownership and fewer manual coordination points.

Engineering Tool

Scheduled Change Detection & Multi-Channel Alerting Service

View Project

Engineering Scope

Scheduled page retrieval, content normalization, snapshot comparison, configurable targets, and Telegram/Gmail alert delivery.

Problem Statement

Manual checks for listing or page changes were slow, repetitive, and easy to miss, especially when users needed fast notification without staring at a browser.

Architecture Overview

Python automation service with page-fetching logic, change detection, scheduled checks, Telegram alerts, Gmail notification support, and local configuration for monitored targets.

Data Flow Explanation

The monitor fetches configured pages, normalizes the relevant content, compares the latest snapshot against previous state, and sends notifications when meaningful changes are detected.

Engineering Decisions

Python kept the automation compact and practical. External notification channels were separated from page monitoring logic so alert delivery could evolve without rewriting the watcher.

Scale & Reliability Considerations

The monitoring loop can add targets through configuration, tune polling intervals by page importance, and isolate notification failures from the core change-detection path.

Outcome

Produced a practical automation tool for real-time webpage change alerts with clear separation between fetching, comparison, state, and notification delivery.

Public Prototype

Typed GraphQL API & React Data Integration Platform

View Project

Engineering Scope

Schema-defined API operations, typed client/server contracts, React views, Apollo-style state flow, and explicit loading/error behavior.

Problem Statement

A full-stack application needed typed frontend data flow, reusable API contracts, and a clearer way to request nested data without over-fetching or scattering REST calls across screens.

Architecture Overview

TypeScript GraphQL server and React client using Apollo-style data flow, schema-defined operations, typed queries, and component boundaries around API state.

Data Flow Explanation

React views request data through GraphQL operations, the server resolves domain fields through typed contracts, and Apollo client state feeds the UI with predictable loading and error paths.

Engineering Decisions

GraphQL was used to make frontend data needs explicit. Typed operation boundaries helped prevent accidental contract drift between the client and server.

Scale & Reliability Considerations

Schema ownership, query structure, and reusable client hooks create a path for adding features without expanding ad hoc endpoint sprawl.

Outcome

Showed full-stack API architecture with typed data contracts, frontend integration, and maintainable GraphQL client/server boundaries.

Prototype / MVP

Commerce Catalog, Cart & Order Workflow MVP

View Project

Engineering Scope

Product discovery, cart state, checkout details, cash-on-delivery order capture, and a foundation for fulfillment operations.

Problem Statement

A focused commerce product needed product discovery, cart state, order submission, and cash-on-delivery handling without overbuilding marketplace or enterprise commerce complexity.

Architecture Overview

TypeScript web application with product listing views, cart state management, checkout flow, order capture, and simple fulfillment assumptions around cash-on-delivery orders.

Data Flow Explanation

Users browse products, add items to cart state, submit checkout details, and create an order record that can be handled through an operational fulfillment workflow.

Engineering Decisions

The MVP kept commerce behavior narrow: product browsing, cart flow, and order creation. This allowed the system to validate the buying workflow before adding heavier payment or inventory infrastructure.

Scale & Reliability Considerations

The architecture leaves room for inventory checks, payment gateways, admin order handling, and catalog filtering once the core product flow is proven.

Outcome

Delivered a lean commerce foundation that shows practical product browsing, cart behavior, and order workflow design.