# Muhammad Humza Riaz — Senior Software Engineer > Muhammad Humza Riaz (Humza Riaz), Senior Software Engineer in Lahore with 7+ years: Laravel, Node.js, Python, AWS and AI. Web apps, APIs and cloud. Website: https://humzariaz.me/ Short index: https://humzariaz.me/llms.txt Structured profile: https://humzariaz.me/profile.json ## About Muhammad Humza Riaz (also written Humza Riaz, M. Humza Riaz) is a Senior Software Engineer based in Lahore, Johar Town, Pakistan. Experienced Software Engineer with more than 7 years of expertise in PHP (Laravel), MVC frameworks, MySQL, Python, and Node.js. Skilled in building scalable web applications, integrating RESTful APIs, and applying AI/ML techniques (Claude, ChatGPT, Gemini) to deliver intelligent, data-driven solutions with 99.9% uptime on AWS. Availability: Open to roles, contracts and projects — let’s talk timelines. - Industry Experience: 7+ years expertise (in Laravel, Python, Node.js & AWS cloud) - Cloud Availability: 99.9% production uptime (sustained on AWS EC2, ALB & auto-scaling groups) - Database Optimization: <100ms response time (sub-100ms queries with Redis & RDS indexing) - Intelligent Systems: 5+ AI/ML models & APIs (health notes, triage, Gemini, Claude & forecasting) ## Experience ### Senior Software Engineer, [Deline Media](https://delinemedia.com) May, 2026 — Present · Lahore, DHA Phase 6 Senior engineer on the backend and cloud side: designing the systems behind the product and keeping them fast and reliable on AWS. Architecting scalable backend microservices, serverless event pipelines on AWS, and high-performance enterprise applications with Laravel, Node.js, and Angular. - Ensured 99.9% production uptime on AWS EC2 with auto-scaling groups & Application Load Balancers (ALB) - Built real-time streaming pipelines using AWS Kinesis for low-latency telemetry processing - Optimized high-availability AWS RDS (MySQL/PostgreSQL) with read replicas and automated backups - Engineered scalable backend microservices and serverless architectures on AWS, leveraging AWS Lambda and Node.js to run event-driven background processing with minimal overhead. - Implemented real-time data ingestion and processing pipelines using AWS Kinesis, enabling low-latency streaming and dynamic telemetry processing across distributed systems. - Provisioned, optimized, and managed high-availability database environments using AWS RDS (MySQL/PostgreSQL), implementing read replicas, query caching, and automated backup strategies. - Designed and scaled high-performance Enterprise Web Applications using Laravel (PHP) for robust API layers and Angular for responsive, reactive user interfaces. - Provisioned and maintained production environments on AWS EC2, configuring auto-scaling groups, load balancers (ALB), and VPC security parameters to ensure 99.9% uptime. - Designed asynchronous message processing workflows combining Node.js, Kinesis, and Lambda to offload heavy computations from main web servers. Technologies: AWS (Lambda, Kinesis, RDS, EC2, ALB, VPC), Laravel (PHP), Node.js, Angular, MySQL, PostgreSQL, Redis, Docker ### Full Stack Developer, [DevStudio](https://devstudio.us) May, 2025 — May, 2026 · Lahore, DHA Phase 5 Built complete web apps end to end, from the database to the screens, and added AI features using models like ChatGPT, Claude and Gemini. Developed full stack applications with Laravel, Node.js, and Angular while deploying AI/ML models and LLM API integrations. - Trained and deployed predictive analytics and automation AI/ML models for intelligent business workflows - Integrated Claude, ChatGPT, and Gemini APIs delivering natural language processing and chatbot features - Maintained production CI/CD pipelines and monitoring systems ensuring continuous delivery - Developed and maintained full stack applications using Laravel and Node.js on the backend and Angular for frontend development. - Designed, trained, and deployed AI/ML models for predictive analytics, automation, and intelligent solutions. - Integrated AI APIs such as Claude, ChatGPT, and Gemini to enhance application features with natural language processing and conversational AI. - Designed and optimized database structures (MySQL, SQL) to improve performance and scalability. - Implemented security best practices, authentication, and authorization protocols across all endpoints. - Monitored and maintained production environments, including CI/CD pipelines and logging/monitoring systems. - Collaborated with cross-functional teams to deliver end-to-end solutions, aligning business requirements with technical implementations. Technologies: Laravel, Node.js, Angular, Python, AI APIs (Claude, ChatGPT, Gemini), MySQL, CI/CD, Security Protocols ### Software Engineer, [Ashlar Global](https://ashlarglobal.com) October, 2021 — May, 2025 · Lahore, Opposite to PCSIR Phase 2 Three and a half years keeping busy, customer-facing systems running: the server code, the APIs (connections between systems) and the screens people used daily. Maintained core server-side functionality, high-traffic APIs using Laravel, and dynamic Vue.js interfaces over 3.5 years. - Maintained and monitored high-traffic production environments across multi-year lifecycles - Optimized database queries and schemas, decreasing page load latencies - Led internal code reviews and implemented automated testing to elevate code quality - Implemented and maintained server-side functionality and APIs using Laravel. - Designed and optimized database structures to improve query performance. - Built and integrated Vue.js interfaces for an enhanced, reactive user experience. - Developed custom plugins and integrated critical third-party services. - Monitored and maintained high-traffic production environments under real customer loads. - Performed security updates and ensured continuous compliance with industry best practices. - Led code reviews and implemented automated testing to maintain robust code quality. - Provided technical support and troubleshooting for business-critical applications. Technologies: Laravel (PHP), Vue.js, MySQL, RESTful APIs, Third-Party Plugins, Automated Testing, Git ### Website Development, [Farraj Consultants](https://www.farraj.com.pk) May, 2021 — September, 2021 · Lahore, MM Alam Road Built web applications for a consultancy, making pages faster with caching and smoother to use. Developed dynamic web applications with Laravel and Vue.js, implementing caching strategies and seamless UI/UX. - Delivered dynamic web applications on schedule with seamless responsive UX - Implemented caching strategies to optimize system performance - Developed dynamic web applications using Laravel and Vue.js. - Collaborated with designers to improve UI/UX, ensuring a seamless frontend experience. - Integrated RESTful APIs and improved overall system efficiency. - Implemented caching strategies to optimize performance on client projects. Technologies: Laravel, Vue.js, RESTful APIs, Caching Strategies, UI/UX Collaboration, JavaScript ### Freelance Software Engineer, Self-employed / Freelance 2020 — May, 2021 · Lahore, Pakistan · Remote Built and maintained web apps for small businesses, including early admin and management systems for healthcare clients. Built and maintained web applications for small clients with PHP (Laravel), MySQL, JavaScript and Vue.js, including early admin and management systems for healthcare-sector clients. - Delivered client web applications from requirements through deployment - Provided ongoing maintenance and support after launch - Built and maintained web applications for small clients using PHP (Laravel), MySQL, JavaScript and Vue.js. - Gathered requirements directly with clients and turned them into working features. - Developed and integrated RESTful APIs for client applications. - Built early admin and management systems, including projects for healthcare-sector clients. - Handled deployment and ongoing maintenance of client projects. Technologies: PHP, Laravel, MySQL, JavaScript, Vue.js, RESTful APIs ## Skills ### Backend Development & Databases Production MVC frameworks, RESTful APIs, and relational databases scaled across high concurrency. The part of the product users never see: storing data safely, handling logins and payments, and answering every request quickly. - **PHP (Laravel)** (Expert, 7 years): RESTful API architectures, MVC design, Eloquent ORM tuning, queues & middleware - **Node.js** (Advanced, 5 years): Asynchronous event loops, real-time WebSockets, microservices, Lambda functions - **Python** (Advanced, 5 years): Data processing pipelines, predictive analytics, AI API orchestration, scripts - **MySQL & SQL Databases** (Expert, 7 years): Schema normalization, composite indexing, query optimization, read replicas - **Redis** (Advanced, 5 years): Distributed caching strategies, pub/sub, session state management, rate limits - **RESTful APIs** (Expert, 7 years): API versioning, authentication (JWT/OAuth), Postman testing, contract design ### Frontend & Reactive UI Modern client architectures, responsive interfaces, and interactive single-page applications. The screens people click on: dashboards, forms and tools that are quick, clear and work on any device. - **Vue.js** (Expert, 6 years): Vue 3 Composition API, Vuex/Pinia state management, reusable component libraries - **Angular** (Advanced, 4 years): TypeScript-based enterprise frontends, RxJS observables, reactive forms - **TypeScript & JavaScript** (Expert, 7 years): Strict typing, modern ESNext, DOM manipulation, asynchronous patterns - **HTML5, CSS3 & Bootstrap** (Expert, 7 years): Responsive mobile-first layouts, cross-browser compatibility, clean styling - **Tailwind CSS** (Advanced, 4 years): Utility-first modern styling, dark/light theme systems, custom animations ### AI, Machine Learning & Automation Applying cutting-edge AI models, predictive intelligence, and automation to production applications. Using AI and prediction models to remove manual work, like drafting replies, sorting requests or forecasting demand, with a person still in control. - **AI APIs (Claude, ChatGPT, Gemini)** (Advanced, 3 years): Conversational agents, automated support workflows, prompt engineering, NLP - **Model Training & Predictive Analytics** (Proficient, 3 years): Demand forecasting models, dynamic pricing logic, classification pipelines - **Data Processing & Automation** (Advanced, 4 years): ETL routines, automated data validation, workflow orchestrations ### AWS Cloud, DevOps & Infrastructure Cloud hosting, containerization, CI/CD pipelines, and high-availability operations. Hosting the product on Amazon Web Services so it stays online, plus the automated testing and release process that keeps updates safe. - **AWS (EC2, Lambda, RDS, Kinesis, ALB)** (Advanced, 5 years): Serverless event architectures, Kinesis streaming, RDS read replicas, VPC security - **Docker & Containerization** (Advanced, 5 years): Containerized local and staging environments, multi-container Docker Compose - **CI/CD Pipelines & Deployment** (Advanced, 5 years): Automated test execution, zero-downtime deployment workflows, GitHub Actions - **Git, GitHub, GitLab, Bitbucket** (Expert, 7 years): Branching strategies (Gitflow), code reviews, PR audits, merge conflict resolution - **Security, RBAC & Caching Strategies** (Expert, 7 years): Role-based access control, query caching, data encryption, PCI/HIPAA compliance - **Postman, JIRA & Agile Collaboration** (Expert, 7 years): Sprint planning, ticket documentation, API testing suites, cross-team synergy ### Additional qualifications - Strong troubleshooting and debugging skills across complex full-stack ecosystems. - Proven ability to enhance application speed using targeted caching, query indexing, and asynchronous offloading. - Extensive experience working in remote, globally distributed agile engineering teams. - Ability to prioritize production issues based on business impact and SLAs. - Proven ability to write clean, maintainable, and well-documented code with comprehensive test coverage. ## Education - Bachelor of Science in Computer Science, Superior University (Lahore, Pakistan). Core Focus on Software Engineering, Database Systems & Algorithms ## Certifications - [Machine Learning with Python](https://www.coursera.org/account/accomplishments/verify/MV4YVO76EWPA) (IBM · Coursera, Apr 2025) - Machine Learning Specialization (Coursera) - [Unsupervised Learning, Recommenders, Reinforcement Learning](https://www.coursera.org/account/accomplishments/verify/SQYU3O2W7XHH) (DeepLearning.AI & Stanford Online · Coursera, Feb 2025) - [Advanced Learning Algorithms](https://www.coursera.org/account/accomplishments/verify/Y3LBETUDMN2T) (DeepLearning.AI & Stanford Online · Coursera, Oct 2024) - [Supervised Machine Learning: Regression and Classification](https://www.coursera.org/account/accomplishments/verify/FYQU7YCTPJEB) (DeepLearning.AI & Stanford Online · Coursera, May 2024) ## Projects (case studies) Client work delivered under contract; source code and live systems are private. ### Health Management System URL: https://humzariaz.me/projects/health-management-system/ Category: Enterprise Cloud & HealthTech Stack: Laravel, Angular, AWS RDS, Node.js, Redis, MySQL, HIPAA One secure system for patient records, staff workflows and appointment booking, with HIPAA-style protection (the US standard for health data) and 99.95% uptime. Healthcare admin platform where each role sees only what it should, and records open in under 85ms. #### Context Patient appointments, medical records and billing lived in separate databases. Every screen that needed all three stitched them together at request time, and queries regularly ran past 900ms. The platform also carried protected health information, so any redesign had to tighten access and encryption at the same time it made things faster. #### Goals - Bring records, scheduling and billing onto one encrypted data layer. - Give doctors, nurses, administrators and patients exactly the access their role needs, and log everything else. - Keep record and schedule queries under 100ms on a multi-tenant workload. #### Role I led the backend: the Laravel API, the RBAC and audit model, the AWS RDS schema and indexing, and the Redis caching layer. I worked with the Angular team on the role-aware screens and with operations on backups and failover. #### Problem Healthcare organizations handled patient appointments, medical records, and billing with fragmented databases, leading to query lag over 900ms and compliance risks. #### Solution Engineered an end-to-end encrypted architecture on AWS RDS (PostgreSQL/MySQL) with Redis caching layers, granular Role-Based Access Control (RBAC), and automated backup strategies. #### Architecture - **Angular client:** Role-aware screens for practitioners, front desk and patients. The UI only renders actions the API will allow, but it never relies on that for security. - **Laravel API and middleware:** Every patient route passes through an authorization middleware that checks the permission for the healthcare guard, writes unauthorized attempts to the audit log, and derives a short-lived decryption key for the request. - **AWS RDS (MySQL/PostgreSQL):** Patient, appointment and billing tables consolidated with encryption at rest and composite indexes shaped around the real query patterns: by practitioner and day, by patient and date range. - **Redis and Node.js workers:** Hot reads such as today’s schedule are cached in Redis with tenant-scoped keys. Node.js workers handle notifications and background jobs off the request path. #### Decisions and trade-offs - **Permission checks in middleware, not in controllers.** Trade-off: Every route pays a small authorization cost, but no endpoint can forget to check, and the audit trail is uniform. - **Tenant-scoped cache keys in Redis.** Trade-off: More keys and slightly lower hit ratio across tenants, in exchange for zero chance of one clinic reading another’s cached data. - **Ephemeral per-request decryption keys.** Trade-off: Extra key-derivation work per request, but long-lived keys never sit in application memory. #### Highlights - A single authorization middleware covering every patient route, with audit logging of denied access. - Consolidated encrypted schema on AWS RDS with automated backups. - Indexes designed from query plans rather than guesses, keeping reads under the 85ms target. #### Challenges - Ensuring strict HIPAA data governance and end-to-end encryption for at-rest and in-transit patient telemetry. Resolution: Encryption at rest on RDS, TLS everywhere in transit, and per-request key derivation so decrypted data only exists for the life of the request. - Fine-grained role authorization policies differentiating medical doctors, nurses, administrators, and patients. Resolution: A permission model keyed by role and resource, enforced in middleware and mirrored in the UI, with denied attempts written to the audit log. - Database indexing optimization maintaining sub-100ms queries under heavy multi-tenant loads. Resolution: Composite indexes per access pattern plus Redis for the hottest reads, verified with query plans under multi-tenant load. #### Security HIPAA-aligned data governance: encryption at rest and in transit, least-privilege roles, audit logging of access attempts, and automated backups. Patient data is never cached under a key that is not tenant-scoped. #### Performance Query latency stays under 85ms through indexing and Redis caching, and the platform runs at 99.95% uptime. Background work moves to Node.js workers so request latency stays flat during heavy periods. #### Testing Feature tests cover every role against every protected route, including the denied cases. Query plans for the main screens are checked as part of review, and backup restores are rehearsed rather than assumed. #### Results - Query Latency: <85 ms - Uptime Reliability: 99.95% - Compliance Grade: HIPAA verified #### Questions **What problem did this solve for the clinic?** Records, appointments and billing were in separate systems, so screens were slow and access was hard to control. Now staff work in one secure system where each role sees only what it should, and records open in under 85ms. **Could you build something similar for my practice or health startup?** Yes. Healthcare platforms with patient records, scheduling and strict access rules are a core part of my experience. Get in touch to discuss scope and pricing. **How is access separated between roles?** Each role maps to a set of permissions on the healthcare guard. The middleware checks the required permission on every patient route and logs any denial. **What keeps queries fast?** Composite indexes built around the real access patterns, plus Redis caching for hot reads like the daily schedule. **Is patient data cached?** Only under tenant-scoped keys, so one clinic can never read another clinic’s cached data. ### Rental Management System URL: https://humzariaz.me/projects/rental-management-system/ Category: AI & Full-Stack Solutions Stack: Laravel, Angular, Python, Claude, ChatGPT, Gemini, Redis A booking system for vehicle and property rentals: no double bookings, prices that adjust to demand, and an AI support assistant. Booking conversion rose 38%. Vehicle and property rentals with prices that follow demand and an AI assistant that answers bookings 24/7. #### Context Fleet and property managers adjusted prices by hand ahead of holidays and peak weekends, usually too late. Customer questions about bookings waited for staff to reply. The business needed pricing that followed demand and support that answered at any hour, without double-booking an asset. #### Goals - Prevent double bookings when several customers reserve the same asset at once. - Price each booking from forecast demand within safe limits. - Answer routine booking questions automatically, accurately, and around the clock. #### Role I built the Laravel booking engine and the Angular booking flow, integrated the Python demand-forecasting service, and designed the LLM support agent and its guardrails. #### Problem Fleet and asset rental managers struggled with manual pricing adjustments during peak holiday demand and slow customer service responses. #### Solution Built full-stack Laravel/Angular booking engine integrated with Python predictive analytics for demand-based pricing models and Gemini/ChatGPT APIs for 24/7 automated conversational support. #### Architecture - **Angular booking flow:** Search, availability calendar, quote and checkout. Quotes come from the API, never computed in the browser. - **Laravel booking engine:** Owns assets, calendars and reservations. Reservations take a lock on the asset’s dates so simultaneous attempts cannot both succeed. - **Python analytics service:** Forecasts a demand index per asset and date from historical occupancy and seasonality. Laravel turns that into a surge multiplier with a hard cap. - **LLM support agent:** Gemini and ChatGPT behind a streaming chat that extracts reservation intent, then calls the booking API for facts instead of answering from the model. - **Redis:** Caches availability and quotes, and holds short-lived locks during reservation. #### Decisions and trade-offs - **Cap the surge multiplier.** Trade-off: Some peak revenue is left on the table, but customers never see an extreme price and the forecast cannot run away. - **LLM answers only from booking API data.** Trade-off: More integration work than a free-form chatbot, but the assistant cannot invent availability or prices. - **Locks on reservation, not on browsing.** Trade-off: Two people can look at the same dates, but only one can complete the booking. #### Highlights - Concurrency-safe reservations on shared availability calendars. - Demand-based dynamic pricing with a long-stay discount rule. - A streaming support assistant that extracts intent and checks real data before replying. #### Challenges - Concurrency locking on vehicle availability calendars during simultaneous multi-user reservation attempts. Resolution: Short-lived locks on the asset and date range during reservation, with the second attempt receiving a clear conflict and fresh availability. - Calibrating dynamic pricing algorithms against historical occupancy data and seasonal trends. Resolution: Calibrated the pricing model against historical occupancy and seasonal patterns, then bounded its output with a minimum and maximum multiplier. - Designing streaming LLM support agents that accurately extract reservation intent without hallucinations. Resolution: Structured intent extraction followed by API calls for facts, so replies are grounded in the booking system rather than the model’s guess. #### Security Payment and personal data stay in the Laravel backend. The LLM receives only the minimum context needed to answer, and its actions are limited to the booking endpoints it is allowed to call. #### Performance Availability and quotes are served from Redis. Support resolution stays under 30 seconds because the assistant answers routine questions without a human hand-off. #### Testing Concurrent reservation tests fire simultaneous bookings at the same asset and assert only one succeeds. Pricing is checked against historical periods, and the assistant is tested with scripted conversations for intent accuracy. #### Results - Booking Conversion: +38% - Support Resolution: <30 sec - Pricing Accuracy: 94.2% #### Questions **What did this change for the business?** Bookings no longer clash, prices follow demand automatically, and an AI assistant answers customer questions using real availability. Booking conversion rose 38%. **Can this work for a different kind of rental?** Yes. The same booking, pricing and support approach works for vehicles, property, equipment or rooms. Get in touch to discuss your setup. **How are double bookings prevented?** A reservation locks the asset’s dates while it completes, so a second simultaneous attempt fails cleanly. **How is the dynamic price set?** A Python model forecasts demand and Laravel converts it to a capped multiplier on the base rate, with a discount for longer stays. **Can the assistant make up an answer?** It extracts intent and then reads availability and prices from the booking API, so it answers from real data. ### Food Ordering & Real-Time Logistics URL: https://humzariaz.me/projects/food-ordering-system/ Category: Full-Stack & E-Commerce Stack: Laravel, Angular, Node.js, Stripe, Redis, WebSockets, MySQL Customers pay securely, kitchens see orders instantly, and couriers are tracked live. Handles up to 3,800 orders an hour with a 99.8% payment success rate. Online ordering that keeps up with the lunch rush, with secure payments and live courier tracking. #### Context Lunch and dinner rushes overloaded the database. Order statuses lagged, couriers waited for updates, and some customers dropped out at checkout when payment confirmation was slow. #### Goals - Keep ordering fast and consistent during peak spikes. - Never lose or duplicate an order between payment and the kitchen. - Show customers and staff live order and courier status. #### Role I designed the order and payment flow in Laravel, the Node.js notification and dispatch services, the Redis caching and queueing, and the Stripe integration, working with the Angular team on the live tracking UI. #### Problem High concurrency during lunch and dinner spikes caused database bottlenecks, delayed order status updates, and checkout payment drop-offs. #### Solution Implemented Redis-backed query caching, asynchronous Node.js order notifications, and atomic Stripe payment intent webhooks ensuring zero dropped orders. #### Architecture - **Angular client:** Menu browsing, cart, checkout with Stripe Elements, and a live tracking view fed by WebSockets. - **Laravel order service:** Menus, orders and payment intents. Successful payment webhooks are verified and dispatched to a high-priority queue. - **Node.js real-time layer:** Pushes order status changes and courier geolocation to clients over WebSockets. - **Redis and MySQL:** Redis caches menus and queues order jobs; MySQL stores orders with transactions kept short to avoid deadlocks. #### Decisions and trade-offs - **Treat the Stripe webhook as the source of truth for payment.** Trade-off: Order confirmation waits for the webhook, but no order is ever created for a payment that did not succeed. - **Push status over WebSockets instead of polling.** Trade-off: A persistent connection layer to run, in return for live updates without hammering the database. - **Cache menus aggressively.** Trade-off: Menu edits need explicit invalidation, but peak traffic stops hitting the database for read-only data. #### Highlights - Signature-verified Stripe webhooks feeding a high-priority order queue. - Live courier tracking streamed to the Angular client. - Peak throughput of 3,800 orders per hour with dispatch under 1.2 seconds. #### Challenges - High order volume concurrency handling without database transaction deadlocks. Resolution: Short transactions, consistent lock ordering and queued post-payment work so high concurrency does not deadlock the database. - Strict PCI-DSS compliance and multi-currency checkout via Stripe Elements. Resolution: Stripe Elements keeps card data off our servers for PCI-DSS scope, with multi-currency handled by Stripe. - Real-time courier geo-location dispatch updates streamed to reactive Angular client. Resolution: Courier positions pushed through the Node.js WebSocket layer straight to the reactive Angular view. #### Security Card data never touches the application thanks to Stripe Elements. Webhooks are verified by signature before any order is processed. #### Performance Redis-backed caching and asynchronous notifications keep order dispatch under 1.2 seconds and support peak throughput of 3,800 orders per hour, with a 99.8% payment success rate. #### Testing Webhook handling is tested with replayed and out-of-order events. Load tests simulate meal-time spikes against the order path, and checkout is tested across currencies. #### Results - Order Dispatch Time: <1.2 sec - Peak Throughput: 3,800 orders/hr - Payment Success Rate: 99.8% #### Questions **Will it keep up on our busiest days?** It was built for peak hours: up to 3,800 orders an hour with a 99.8% payment success rate, and orders are never lost when payment succeeds. **Are customer card details safe?** Yes. Card entry is handled by Stripe, so card numbers never touch your servers. **How are orders kept from being dropped?** Orders are created from verified Stripe payment events and processed through a queue, so a successful payment always produces exactly one order. **How does live tracking work?** A Node.js service pushes status and courier location over WebSockets to the Angular client. **Is it PCI compliant?** Card entry uses Stripe Elements, so card data stays with Stripe and out of our systems. ### Enterprise Content Management System URL: https://humzariaz.me/projects/enterprise-cms/ Category: Enterprise Web Applications Stack: Laravel, Vue.js, MySQL, Redis, RBAC, Docker A content management system where authors, editors and publishers each have the right permissions across business units. Pages render in under 60ms and pass a full security audit. A publishing system for large teams: clear approval steps, fast pages and a full record of every change. #### Context Editorial teams across several business units published to multiple publications. Each needed its own approval chain, and changes had to be traceable after the fact. #### Goals - Model author, editor and publisher permissions per business unit. - Serve pages fast from cache while keeping published changes visible immediately. - Make custom rich-text content safe to render. #### Role I architected the Laravel core and permission model, the Redis caching and invalidation strategy, the audit log, and the content sanitization, and worked on the Vue.js editor and workflow screens. The stack ran in Docker. #### Problem Corporate editorial teams required granular publishing approval workflows with distinct permissions for authors, editors, and publishers across multiple publications. #### Solution Architected modular Laravel core with Vue.js frontend, multi-level Redis content caching, and automated audit logs tracking every content modification. #### Architecture - **Vue.js editor and workflow:** WYSIWYG editing, review queues per role, and a publishing panel that shows where each article sits in the chain. - **Laravel modular core:** Articles, publications, business units and roles as separate modules, with publishing done in a single database transaction. - **Redis multi-level cache:** Article pages and feeds cached with tags, so a publish can flush exactly the article and its category. - **Audit log:** Every create, update, publish and role change written alongside the content change in the same transaction. #### Decisions and trade-offs - **Tag-based cache invalidation.** Trade-off: Cache keys need careful tagging, but publishing flushes only what changed instead of the whole site. - **Audit writes inside the publish transaction.** Trade-off: Slightly longer transactions, but there is never a publish without its audit record. - **Sanitize on save, not on render.** Trade-off: Stored content is already clean, so every renderer is safe by default. #### Highlights - Nested permission hierarchies across business units. - Surgical cache invalidation on publish with a 96.4% cache hit ratio. - A full audit trail of content and role changes. #### Challenges - Complex nested permission hierarchies across multiple corporate business units. Resolution: A role and unit hierarchy evaluated in policies, so a user can be an editor in one unit and an author in another. - Dynamic page asset caching with immediate surgical cache invalidation on publish. Resolution: Tagged Redis caching with targeted flushes for the article and its category inside the publish transaction. - Preventing XSS and SQL injection across custom WYSIWYG markup rendering. Resolution: Server-side sanitization of WYSIWYG markup and parameterized queries throughout, which kept the security audit at 100% pass. #### Security Role policies on every action, sanitized rich text to prevent XSS, parameterized queries against SQL injection, and an immutable audit log. #### Performance Pages render in under 60ms thanks to multi-level Redis caching, while targeted invalidation keeps published content fresh. #### Testing Policy tests cover each role in each unit. Sanitization is tested against known XSS payloads, and publish flows are tested to confirm the right cache tags are flushed. #### Results - Page Render Time: <60 ms - Cache Hit Ratio: 96.4% - Security Audit: 100 % pass #### Questions **Who is a system like this for?** Larger organisations where many people publish content and each change needs the right approval and a clear record. **Can my team publish without a developer?** Yes. Authors, editors and publishers each have their own steps and permissions, and publishing updates the live site instantly. **How do approvals work?** Authors write drafts, editors review and approve, and publishers put them live. Each step is permission-checked and logged. **How is content kept fast and fresh?** Pages are cached in Redis with tags; publishing flushes only the affected article and category. **How is rich text made safe?** Markup is sanitized on save, so stored content cannot carry scripts. ### Customer Relationship Management (CRM) URL: https://humzariaz.me/projects/crm-web-application/ Category: Enterprise Web Applications Stack: Laravel, Bootstrap, JavaScript, MySQL, RESTful APIs, JIRA A customer relationship management (CRM) app for sales teams: pipeline stages, automatic call and email logging, and reports in under 250ms. Lead tracking efficiency rose 45%. A sales CRM that logs every call and email automatically, so leads stop slipping through the cracks. #### Context Sales communication lived in personal inboxes and spreadsheets. Leads were lost between reps, nobody could see who last spoke to a customer, and satisfaction reporting was pieced together by hand. #### Goals - Log every customer interaction automatically. - Track each lead through clear pipeline stages. - Keep each team’s leads isolated and give managers fast reports. #### Role I built the Laravel application and its data-isolation middleware, the pipeline and interaction models, the reporting queries, and the RESTful webhook integrations for email and calendar. Work was tracked in JIRA. #### Problem Disorganized sales communication channels led to lost leads, lack of interaction accountability, and disjointed customer satisfaction reporting. #### Solution Created an intuitive management portal with automated interaction logging, pipeline stage tracking, and customized Laravel middleware enforcing data isolation. #### Architecture - **Bootstrap and JavaScript front end:** Pipeline board, lead profiles with interaction history, and analytics dashboards. - **Laravel core:** Leads, contacts, stages and interactions, with custom middleware that scopes every query to the user’s tenant. - **Webhook integrations:** RESTful webhooks from email and calendar providers create interaction records automatically. - **MySQL reporting:** Aggregation queries for monthly revenue trends and conversion rates, shaped for fast report generation. #### Decisions and trade-offs - **Tenant scoping in middleware and global query scopes.** Trade-off: Cross-tenant admin features need explicit opt-out, but accidental leaks are prevented by default. - **Webhooks over manual logging.** Trade-off: More integration surface to maintain, but reps no longer have to remember to log calls and emails. #### Highlights - Automatic interaction logging from email and calendar. - Lead tracking efficiency up 45%. - Reports generated in under 250ms. #### Challenges - Enforcing strict tenant isolation to prevent sensitive sales leads leaks. Resolution: Custom Laravel middleware and global scopes that bind every query to the tenant, giving 100% data security compliance. - Building reactive analytics dashboards aggregating monthly revenue trends and conversion rates. Resolution: Pre-shaped aggregation queries for revenue and conversion dashboards, so reports return in under 250ms. - Integrating email and calendar synchronization with RESTful API webhooks. Resolution: Webhook endpoints for email and calendar events that create interaction records on the right lead. #### Security Tenant isolation enforced in middleware and query scopes, authenticated webhook endpoints, and role-based access to reports. #### Performance Report generation stays under 250ms through indexed aggregation queries tailored to each dashboard. #### Testing Isolation tests attempt cross-tenant reads and assert they fail. Webhook handlers are tested with sample provider payloads, and report queries are checked against known datasets. #### Results - Lead Tracking Efficiency: +45% - Report Generation: <250 ms - Data Security Compliance: 100% #### Questions **How does this help a sales team?** Calls and emails are logged automatically, every lead has a clear stage, and reports load in under 250ms. Lead tracking efficiency rose 45%. **Can it replace our spreadsheets?** That is exactly the job it was built for: one shared system instead of copies of a spreadsheet that disagree. **How are leads kept private between teams?** Middleware and global query scopes bind every query to the user’s tenant. **Do reps log interactions by hand?** No. Email and calendar webhooks create interaction records automatically. ### Real Estate Management & Analytics URL: https://humzariaz.me/projects/real-estate-management/ Category: Enterprise Cloud & Analytics Stack: Laravel, Vue.js, RESTful APIs, MySQL, Cloudflare, Postman A property management platform that brings rental yields, valuation history and maintenance into one place, with fast multi-filter search and quick public listings. One dashboard for a property portfolio: yields, valuations and maintenance, with search in under 70ms. #### Context Portfolio managers compared rental yields in spreadsheets, tracked maintenance in email, and had no single view of regional price trends. #### Goals - One view of every asset with yield, valuation and maintenance status. - Fast search across price, size, neighborhood and yield. - Public listings that load quickly without caching the admin side. #### Role I built the Laravel backend and query layer, the spatial indexing and search, the valuation API integrations, and the Cloudflare caching rules, and worked on the Vue.js interface. APIs were documented and tested in Postman. #### Problem Real estate portfolio managers lacked unified tools to compare rental yields, track maintenance tickets, and query regional asset price trends. #### Solution Built a responsive Vue.js interface powered by optimized Laravel backend queries, spatial database indexing, and external property valuation API feeds. #### Architecture - **Vue.js interface:** Portfolio dashboard, multi-filter property search, valuation history and maintenance tracking. - **Laravel API:** Optimized queries for search and valuation history, with spatial indexes for location-based filters. - **External valuation feeds:** Property valuation APIs feed historical valuations into MySQL on a schedule. - **Cloudflare:** Caches public listing pages at the edge while bypassing cache for authenticated admin routes. #### Decisions and trade-offs - **Spatial indexes for location filters.** Trade-off: More complex schema, but location searches avoid full scans. - **Edge-cache only public pages.** Trade-off: Two caching behaviors to reason about, but admins always see live data. #### Highlights - Multi-parameter search under 70ms. - Full portfolio visibility in one dashboard. - API responses around 95ms. #### Challenges - Complex multi-parameter spatial property search (price, square footage, neighborhood, yield). Resolution: Composite and spatial indexes that match the search filters, so combined price, size, area and yield queries stay under 70ms. - Database query optimization handling tens of thousands of historical property valuations. Resolution: Query optimization and summarization of historical valuations so charts read a compact series instead of every raw record. - Cloudflare caching configuration for public property listings while keeping admin portals dynamic. Resolution: Cloudflare rules that cache public listing paths and bypass cache for admin and authenticated routes. #### Security Admin routes are authenticated and never cached at the edge. Valuation API keys stay server-side. #### Performance Search queries run under 70ms and API responses around 95ms, with Cloudflare absorbing public listing traffic. #### Testing Search endpoints are tested with Postman collections covering filter combinations, and caching rules are verified to bypass authenticated routes. #### Results - Search Query Latency: <70 ms - Portfolio Visibility: 100% - API Response Time: 95 ms #### Questions **What does a property manager get from this?** One place to see rental yields, valuation history and maintenance across the portfolio, with search results in under 70ms. **Could it list properties publicly too?** Yes. Public listing pages load quickly and stay in sync with the internal data. **What can managers search by?** Price, square footage, neighborhood and rental yield, in any combination. **Where do valuations come from?** External property valuation APIs, stored historically so trends can be charted. ### Client Hiring Portal URL: https://humzariaz.me/projects/engineer-portfolio/ Category: Full-Stack & Product UI Stack: React, TypeScript, Tailwind CSS, Vite, Bun A React and TypeScript site that presents real case studies, filters work by skill, and lets a visitor choose a team role, a dedicated contract, or a scoped project. This site: a portfolio where a company can read the work, pick how to engage, and send a brief. #### Context Hiring managers reading a flat résumé could not tell which systems were in production, what stack sat behind them, or how to start a conversation. #### Goals - Present real case studies with stack and outcomes. - Let visitors filter work by skill. - Offer clear engagement paths and a contact flow that does not require a PDF back-and-forth. #### Role Design and build end to end: React and TypeScript front end, content model, theming, motion and the contact flow, built with Vite and Bun. #### Problem Hiring managers were reading a flat résumé and still could not tell which systems were production, which stack sat behind them, or how to start a conversation. #### Solution Shipped a single-page product with case-study modals, skill-to-project mapping, a timezone-aware theme, and a contact path that opens a ready brief in the mail client. #### Architecture - **React + TypeScript:** A typed content model drives the home page, case studies, services and slide decks from one data file. - **Skill-to-project mapping:** Skills reference project ids directly, so filters resolve reliably instead of matching tag strings. - **Theme engine:** Picks light or dark from the visitor’s local time before first paint, with a manual override that persists. - **Contact path:** Engagement options open a prefilled brief in the visitor’s mail client. #### Decisions and trade-offs - **Resolve filters by project id.** Trade-off: Skills need explicit links to projects, but filters never miss because of naming differences. - **Mail-client brief instead of a form backend.** Trade-off: No form analytics, but no backend to run and nothing to spam. #### Highlights - No theme flash on first paint. - Three engagement paths. - Case studies backed by one typed data source. #### Challenges - Theme had to match the visitor local day or night before the first paint, with a manual override that sticks. Resolution: An inline script decides the theme from the visitor’s timezone before React mounts, then respects a saved manual choice. - Skill names and project tags did not line up, so filters had to resolve by project id. Resolution: Skills carry relatedProjectIds, so filtering is a lookup rather than fuzzy tag matching. - Long pages needed inertial scroll that still landed section titles under a fixed nav. Resolution: Inertial scrolling with offsets that land section titles below the fixed navigation. #### Security A static site with no backend or stored visitor data; the contact flow hands off to the visitor’s own mail client. #### Performance Vite code-splitting and lazy-loaded modals keep the initial bundle small; heavy components load only when opened. #### Testing TypeScript checks and lint run on every build, and pages are checked visually across themes and breakpoints. #### Results - First paint theme: 0 flash - Engagement options: 3 paths - Case studies: 7 live #### Questions **Why include a portfolio site as a project?** It shows how I present work to non-technical readers, keep a site fast, and make it easy for someone to get in touch. **Can you build a site like this for my business?** Yes, especially if it needs to explain technical work clearly. Get in touch to discuss scope. **Why no contact form?** A prefilled email brief reaches a real inbox with no backend to maintain. **How does the theme work?** It follows the visitor’s local day or night before first paint, and a manual choice sticks. ### Clinical Notes AI API URL: https://humzariaz.me/projects/clinical-notes-ai/ Category: Health AI Stack: Python, Claude, Gemini, REST, HIPAA An AI service that reads a clinical note and fills in the fields the clinic already uses. Every value must come from the note itself, so no invented doses are ever stored. AI that turns a doctor’s free-text note into structured problems, medications and follow-ups. #### Context Clinicians wrote a note, then typed the same history again into the discrete fields that billing and follow-up screens required. #### Goals - Turn free-text notes into structured problems, medications and follow-ups. - Store only fields the clinic already uses, and nothing the note does not support. - Keep patient text out of logs. #### Role I designed and built the Python extraction service, the closed schema and validator, the LLM prompts for Claude and Gemini, and the logging policy. #### Problem Clinicians typed the same history twice: once in the note, again into discrete fields the billing and follow-up screens required. #### Solution A Python service sends the note to Claude or Gemini with a closed schema, then rejects any key that is not problems, medications, or follow-up. #### Architecture - **REST endpoint:** Accepts a note and returns structured JSON in a fixed schema. - **LLM call:** Claude or Gemini with a system prompt that asks for the schema only and forbids invented fields. - **Python validator:** Parses the response, drops unknown keys, and rejects any value without a source span in the note. - **Chart write:** Only validated problems, medications and follow-ups reach the chart. #### Decisions and trade-offs - **Closed schema over open extraction.** Trade-off: Less information captured, but every stored field is one the clinic actually uses. - **Require a source span for each value.** Trade-off: Some true facts are dropped if the model cannot point to them, but nothing invented is stored. - **Two model providers.** Trade-off: Two prompts to maintain, but no single-vendor dependency. #### Highlights - Closed-schema extraction with zero invented doses stored. - One API path for every note. - Patient text excluded from application traces. #### Challenges - The model would invent a dose that was not in the note. The parser drops any value without a source span. Resolution: The parser drops any value that has no source span in the note, so an invented dose never reaches the chart. - Notes mixed English shorthand and abbreviations. The schema had to accept both without guessing a diagnosis. Resolution: The schema accepts shorthand and abbreviations as text, without inferring a diagnosis the note does not state. - Patient text could not be logged in application traces. Resolution: Logging records request metadata and validation outcomes only, never the note content. #### Security Notes are processed in memory and never logged. The schema is closed, so the model cannot add fields that would carry extra patient data into storage. #### Performance One synchronous extraction call per note, with validation in Python adding negligible overhead to the model call. #### Testing A fixture set of notes with expected outputs, including notes designed to tempt the model into inventing doses or diagnoses, runs against the validator. #### Results - Schema reject: closed keys - Invented dose: 0 stored - Extract path: 1 API #### Questions **Does the AI ever make things up?** It is not allowed to store anything that is not in the original note. If the AI suggests a value with no source in the text, it is dropped. **What does this save a clinic?** The second typing pass: problems, medications and follow-ups land in structured fields instead of being copied by hand. **What happens if the model invents something?** Values without a source span in the note are dropped before anything is stored. **Which models are used?** Claude or Gemini, behind the same schema and validator. ### Lab Orders & Results API URL: https://humzariaz.me/projects/lab-orders-api/ Category: Health APIs Stack: Laravel, Node.js, MySQL, Redis, REST, AWS Replaced emailed lab orders and shared spreadsheets with an API (a secure system-to-system connection). Results read in under 90ms and duplicates are never applied twice. A secure connection between clinics and the lab: orders go in, results come back fast, and each clinic sees only its own. #### Context Lab orders traveled by email and shared spreadsheets. Results arrived late, and a loose query could show one clinic another clinic’s panel. #### Goals - A versioned API for placing orders and receiving results. - Strict tenant isolation on every token. - Idempotent result intake and signed notifications. #### Role I designed the API contract and built the Laravel endpoints, Node.js result-intake workers, Redis caching and locks, token scopes, and webhook signing on AWS. #### Problem Orders lived in email and shared spreadsheets. Results arrived late, and one clinic could see another clinic’s panel if the query was loose. #### Solution Shipped a versioned Laravel API with Node workers for result intake, Redis for hot reads, and tenant scopes so a token only opens its own orders. #### Architecture - **Versioned Laravel API:** Orders and results endpoints with scoped tokens; a token only opens its own clinic’s orders. - **Node.js intake workers:** Receive result payloads from labs and write them idempotently. - **Redis:** Serves hot result reads and provides short locks keyed by order and idempotency key. - **Signed webhooks:** Notify the ordering clinic, with signatures that remain valid on retry. #### Decisions and trade-offs - **Idempotency keys on result posts.** Trade-off: Labs must send a key, but duplicate posts become harmless no-ops. - **Tenant scope in the token, not the query string.** Trade-off: Token management is stricter, but clients cannot ask for another clinic’s data. #### Highlights - Result reads under 90ms. - Zero duplicate posts applied. - Zero tenant leaks in review. #### Challenges - Result payloads arrived twice. Idempotency keys had to make the second post a no-op. Resolution: A lock on order plus idempotency key and a firstOrCreate write, so the second identical post returns the existing result. - A clinic token could not be allowed to enumerate another site’s patients. Resolution: Token scopes bound to the clinic, enforced on every query, so enumeration across sites is impossible. - Webhook retries had to stay signed after the original request was gone. Resolution: Webhook signatures computed per delivery attempt, so retries stay verifiable after the original request is gone. #### Security Scoped tokens per clinic, permission checks such as results:write, and signed webhooks. #### Performance Redis-backed hot reads keep result retrieval under 90ms when a panel posts. #### Testing Contract tests per version, duplicate-post tests, and cross-tenant access tests that must fail. #### Results - Result read: <90 ms - Duplicate posts: 0 applied - Tenant leak: 0 in review #### Questions **What did this replace?** Lab orders sent by email and tracked in shared spreadsheets. Now orders and results move automatically and securely between clinics and the lab. **Can clinics see each other’s data?** No. Each clinic can only see its own orders and results. **What if a lab posts the same result twice?** The idempotency key makes the second post a no-op that returns the original result. **Can one clinic read another’s orders?** No. Tokens are scoped to a clinic and every query enforces that scope. ### Patient Message Triage API URL: https://humzariaz.me/projects/care-triage-api/ Category: Health AI Stack: Node.js, Claude, ChatGPT, Redis, RBAC, REST An AI routing service: a message with a refill and a new symptom is split and sent to the nurse and clinician queues. It suggests a route, never a diagnosis. AI that reads patient messages and sends each request to the right team, in under 2 seconds. #### Context Patient messages often mixed a refill request with a new symptom. One label sent the whole thread to one desk, and urgent symptoms waited behind billing. #### Goals - Split mixed messages into separate intents. - Route each intent to a queue the clinic actually staffs. - Return a route, never a diagnosis or treatment. #### Role I built the Node.js service, the prompts for Claude and ChatGPT, the closed label set and RBAC map, and the Redis routing cache. #### Problem One message often held a refill and a new symptom. A single label sent the whole thread to the wrong desk, and urgent swelling waited behind billing. #### Solution A Node service calls Claude or ChatGPT with a fixed label set, stores the route in Redis for the shift, and refuses labels outside the clinic’s RBAC map. #### Architecture - **REST endpoint:** Accepts a patient message and returns one route per intent. - **LLM classification:** Claude or ChatGPT splits intents and labels each from a fixed set. - **RBAC label map:** Filters out any label the clinic has not mapped to a staffed queue. - **Redis:** Stores routes for the shift so queues read quickly. #### Decisions and trade-offs - **Closed enum of labels.** Trade-off: New intents need a config change, but the model cannot invent a queue. - **Routes, not advice.** Trade-off: Less automation, but triage stays a sorting step and clinical judgment stays with people. #### Highlights - Routing in under 2 seconds. - Closed label set enforced after the model. - Automatic first-pass inbox sort. #### Challenges - Mixed intents had to split instead of picking the first sentence. Resolution: The prompt asks for all intents, and the schema expects a list, so a message with a refill and a symptom produces two routes. - The model could not invent a queue the clinic did not staff. Resolution: Model output is filtered against the clinic’s RBAC map; unmapped labels are refused. - A triage suggestion is not a diagnosis, so the API returns a route, not a treatment. Resolution: The API returns a route only and the prompt forbids diagnosis, keeping triage separate from treatment. #### Security RBAC controls which queues exist per clinic, and only routes are stored, not clinical conclusions. #### Performance Each message routes in under 2 seconds, with shift routes cached in Redis. #### Testing Message fixtures with mixed intents, out-of-set labels, and requests for advice, each with expected routes. #### Results - Route time: <2 sec - Label set: closed enum - Inbox sort: auto first pass #### Questions **Does it give patients medical advice?** No. It only decides which team should see a message. Clinical decisions stay with clinicians. **What does it change for staff?** Messages reach the right queue in under 2 seconds, so nurses and clinicians spend less time sorting the inbox. **What if a message has two requests?** Each intent becomes its own route to its own queue. **Does it give medical advice?** No. It returns a route only. ### Vitals Ingestion Pipeline URL: https://humzariaz.me/projects/vitals-stream-api/ Category: Health Data & Cloud Stack: Python, AWS Kinesis, Lambda, Redis, REST A data pipeline that takes bursts of readings from medical devices, drops impossible or duplicate values, and keeps the latest good reading ready for the app to show. Device readings like heart rate and blood pressure, cleaned up and shown live in under 100ms. #### Context Device vendors posted vitals in bursts. Impossible samples, like a heart rate of zero or a duplicated timestamp, landed in the chart next to real readings. #### Goals - Absorb bursts without dropping data. - Reject impossible and duplicate samples. - Serve the latest reading without scanning the raw stream. #### Role I designed the pipeline on AWS and wrote the Python validation Lambda, the Redis latest-value store, and the REST read API. #### Problem Device vendors posted bursts of vitals. Bad samples (a heart rate of 0, a duplicated timestamp) landed in the chart next to real ones. #### Solution Kinesis took the burst, a Python Lambda dropped impossible values, and Redis held the latest accepted reading for the query API. #### Architecture - **AWS Kinesis:** Takes bursts from devices and buffers them for processing. - **Python Lambda:** Applies validation rules, drops impossible values and duplicates, and stamps server time. - **Redis:** Holds the latest accepted reading per patient and signal. - **REST API:** Reads the latest values from Redis instead of the stream. #### Decisions and trade-offs - **Server timestamp wins.** Trade-off: Device time is ignored for ordering, but out-of-order clocks cannot corrupt the chart. - **Latest value in Redis.** Trade-off: History is served elsewhere, but the common read is instant. #### Highlights - Latest reads under 100ms. - Rule-based sample rejection in Python. - Kinesis absorbing ingest bursts. #### Challenges - Out-of-order device clocks had to lose to the server timestamp. Resolution: The Lambda orders samples by server receipt time, so device clock drift cannot reorder readings. - A spike of identical payloads could not inflate the chart. Resolution: Duplicate payloads are detected and dropped before they reach storage. - The read API had to avoid scanning the raw stream on every page load. Resolution: The read API serves the latest value from Redis rather than scanning the stream on every page load. #### Security Device and API access are authenticated, and processing happens inside the AWS account without exposing the raw stream. #### Performance Latest-reading queries return in under 100ms from Redis, independent of stream volume. #### Testing Replay tests with recorded bursts, impossible values and duplicate payloads verify what is accepted and rejected. #### Results - Latest read: <100 ms - Rejected samples: rules python - Ingest: Kinesis burst #### Questions **What happens to bad readings?** Impossible values and duplicates are filtered out, so the app shows the last good reading, not the last packet. **Is it fast enough for live monitoring?** Yes. The latest accepted reading is served in under 100ms. **What counts as a bad sample?** Impossible values, such as a heart rate of zero, and duplicate payloads. **Why not read from Kinesis directly?** Scanning the stream per page load is slow; Redis keeps the latest value ready. ### Clinic Partner API URL: https://humzariaz.me/projects/clinic-partner-api/ Category: API Platform Stack: Laravel, OAuth, REST, MySQL, Postman, Webhooks A versioned partner API for clinics: scoped access, safe retries that never double-book, signed notifications, and ready-made documentation in Postman. One documented, secure API so outside systems can book appointments and get updates without custom builds. #### Context Every new clinic integration was a private endpoint and a Slack thread. Partners could not book or read a schedule without a custom build. #### Goals - A public, versioned contract partners can build against. - Safe booking under retries. - Webhooks partners can trust. #### Role I designed and published /v2: OAuth scopes, the error catalog, rate limits, idempotent booking, webhook signing and rotation, and the Postman collection. #### Problem Each new clinic integration was a private endpoint and a Slack thread. Partners could not book or read a schedule without a custom build. #### Solution Published /v2 with scoped OAuth, a written error catalog, rate limits, and a Postman collection that matches the live contract. #### Architecture - **Laravel /v2 routes:** Scoped OAuth middleware and partner rate limits on every route. - **Booking with idempotency:** A replayed booking request returns the original appointment. - **Webhooks:** Signed deliveries that fail closed on signature mismatch, with secret rotation. - **Postman collection:** Matches the live contract and serves as partner documentation. #### Decisions and trade-offs - **Ship v2 alongside v1.** Trade-off: Two versions to run for a while, but existing clients keep working. - **Fail closed on bad signatures.** Trade-off: Misconfigured partners see failures quickly, which is safer than silently accepting. #### Highlights - A stable v2 contract. - Booking replay returns one appointment. - A Postman collection as partner docs. #### Challenges - v1 clients still called old paths. v2 had to ship without breaking them. Resolution: v1 paths stay routed to their original handlers while v2 lives under its own prefix. - A replayed booking request had to return the original appointment, not a second one. Resolution: Idempotency keys map a replayed request to the appointment it already created. - Webhook secrets rotated without dropping in-flight deliveries. Resolution: Overlapping secret windows during rotation, so in-flight deliveries still verify. #### Security OAuth scopes per capability, rate limiting per partner, and signed webhooks that fail closed. #### Performance Rate limits protect the platform from any single partner, and idempotency removes duplicate work from retries. #### Testing Contract tests per version, replay tests for booking, and signature tests across secret rotation. #### Results - Contract: v2 stable - Booking replay: 1 appointment - Partner docs: Postman collection #### Questions **Why does a clinic need a partner API?** So other companies can book appointments and receive updates through one documented connection, instead of a custom build for each partner. **What if a partner sends the same booking twice?** The second request returns the original booking, so nothing is ever double-booked. **What happens if a partner retries a booking?** The same idempotency key returns the original appointment. **Did v1 clients break?** No. v1 paths stayed in place while v2 launched. ### Appointment No-Show Risk Model URL: https://humzariaz.me/projects/no-show-risk-model/ Category: Applied Machine Learning Stack: Python, scikit-learn, Pandas, Laravel, MySQL, Redis A prediction model built on past booking history that sorts tomorrow’s appointments into risk bands, each with a short reason, so reminder calls go where they matter. Machine learning that predicts which appointments are likely to be missed, so staff confirm those first. #### Context Reminder calls went out in schedule order, so staff spent their time on patients who always attend while the slots that went empty were never confirmed. The clinic had years of booking history in MySQL but no way to use it to prioritize the day. #### Goals - Score tomorrow’s appointments by the chance they will be missed. - Give staff a short reason for each score, not just a number. - Fit into the existing Laravel scheduler without changing how staff work. #### Role I framed the problem, built the feature pipeline and model in Python with scikit-learn and Pandas, designed the evaluation, and integrated the scores into the Laravel scheduler through Redis. #### Problem Reminder calls went out in schedule order. Staff spent the morning on patients who always attend, and the slots that went empty were the ones nobody had time to confirm. #### Solution A nightly Python job builds features from past bookings in MySQL, scores tomorrow’s appointments with a regularized logistic regression model, and the Laravel scheduler reads the risk band from Redis to sort the confirmation queue. #### Architecture - **Feature build (Pandas):** A nightly job reads past bookings from MySQL and builds features known before the visit: lead time, weekday, slot hour, visit type, and prior attendance history. - **Model (scikit-learn):** A pipeline of scaling, one-hot encoding and regularized logistic regression with balanced class weights. - **Risk bands:** Probabilities are converted into three bands with thresholds chosen on validation data, plus the top contributing features from the coefficients. - **Laravel integration:** Bands are written to Redis; the scheduler sorts the confirmation queue by band. #### Decisions and trade-offs - **Logistic regression over a more complex model.** Trade-off: Possibly less raw predictive power, but coefficients give staff a clear reason for each band. - **Time-based train and test split.** Trade-off: Less training data for the latest period, but evaluation reflects how the model will be used: on future appointments. - **Three bands instead of a raw probability.** Trade-off: Less precision on screen, but staff act on bands, not decimals. #### Highlights - Applies supervised classification from the Supervised Machine Learning: Regression and Classification course: logistic regression, feature scaling, regularization and decision thresholds. - Builds the end-to-end workflow in Python taught in Machine Learning with Python, from Pandas features to a scikit-learn pipeline. - Explainable output: every band comes with the features that pushed it up. #### Challenges - Missed visits are the minority class, so the model is judged on precision and recall at the chosen threshold, not on raw accuracy. Resolution: Balanced class weights and evaluation on precision and recall at the chosen threshold, with the threshold selected on a validation set. - Features had to come only from data known before the visit, so nothing from the appointment outcome leaks into training. Resolution: Features are restricted to what is known at booking time, and the split is by date so no future information leaks into training. - Staff need a reason, not a score, so each band ships with the top contributing features from the model coefficients. Resolution: Coefficient-based explanations attached to each band, shown in the queue next to the appointment. #### Security The model reads booking metadata, not clinical notes. Scores are stored as bands in Redis with the same access rules as the schedule. #### Performance Scoring runs nightly in batch, so the scheduler reads precomputed bands with no model call at request time. #### Testing Held-out evaluation on a later time window, checks for leakage in feature generation, and a review of explanations with front-desk staff before rollout. #### Results - Model: Logistic regression - Evaluation: Held-out time split - Output: 3 risk bands #### Questions **What does this mean for the front desk?** Staff get tomorrow’s appointments sorted by risk, with a short reason for each, so reminder calls go to the bookings most likely to be missed first. **Does it decide who gets an appointment?** No. It only changes the order of the reminder list. Nobody is refused a booking. **Which certification does this apply?** Supervised Machine Learning: Regression and Classification, and Machine Learning with Python. **Why logistic regression?** It is a strong baseline for binary outcomes and its coefficients explain each score. **Does the model change who gets an appointment?** No. It only orders the confirmation call list. ### Rental Recommendation Engine URL: https://humzariaz.me/projects/stay-recommender/ Category: Recommender Systems Stack: Python, TensorFlow, NumPy, Laravel, Redis, AWS A recommendation engine that learns from booking history, gives new listings a fair chance from day one, and only suggests what is available for the searched dates. Personal suggestions for the next vehicle or property a renter is likely to book, including brand-new listings. #### Context The rental listing page showed the same popular assets to every visitor. New listings rarely surfaced, and returning renters started every search from scratch. #### Goals - Personalize suggestions from booking history. - Give new listings a fair chance before they have bookings. - Never suggest something unavailable for the searched dates. #### Role I designed the recommender: collaborative filtering and content-based models in TensorFlow and NumPy, the blending and availability filter, and the Redis serving layer consumed by the Laravel front end on AWS. #### Problem The listing page showed the same popular assets to everyone. New listings never surfaced, and repeat renters had to search from scratch each time. #### Solution Trained a collaborative filtering model on implicit booking signals, added a content-based model on listing features for cold-start items, and blended both into a ranked list cached per user in Redis for the Laravel front end. #### Architecture - **Interaction data:** Views and bookings are turned into implicit feedback, with bookings weighted above views. - **Collaborative filtering:** Learns user and item vectors from interactions to find assets similar renters booked. - **Content-based model:** Two neural towers map user and listing features into the same space, so new listings can be scored from their attributes. - **Blend and serve:** Scores are blended, filtered by availability, and cached per user in Redis for the Laravel listing page. #### Decisions and trade-offs - **Blend two models instead of choosing one.** Trade-off: More moving parts, but both returning renters and new listings are covered. - **Precompute suggestions.** Trade-off: Suggestions are refreshed in batch rather than instantly, but page loads read straight from Redis. - **Availability filter at serve time.** Trade-off: A small extra step per request, but no suggestion is ever unbookable. #### Highlights - Applies collaborative filtering and content-based filtering with neural networks from Unsupervised Learning, Recommenders, Reinforcement Learning. - Uses the TensorFlow modeling practices from the Machine Learning Specialization. - A cold-start path so new listings surface from day one. #### Challenges - New listings have no bookings, so the content model carries them until real interactions arrive. Resolution: The content-based model scores new listings from their features until enough interactions arrive for collaborative filtering. - Booking data is implicit feedback; views and bookings had to be weighted differently instead of treated as ratings. Resolution: Bookings and views weighted as implicit signals, with mean normalization so heavy users do not dominate. - Suggestions must never include assets that are unavailable for the dates the renter searched. Resolution: Availability checked against the booking calendar before suggestions are returned. #### Security Models train on interaction IDs and listing features, not personal details. Suggestions are cached per user under keys only that user’s session can read. #### Performance Suggestions are precomputed and served from Redis, so the listing page adds no model latency. #### Testing Offline ranking evaluation on held-out interactions, cold-start checks with listings removed from training, and availability tests on suggested items. #### Results - Models: 2 blended - Cold start: content fallback - Serving: Redis precomputed #### Questions **What does a renter see?** Suggestions based on what similar renters booked, filtered to listings that are actually available for their dates. **Do new listings get a chance?** Yes. New listings are matched on their features until they have booking history of their own. **Which certification does this apply?** Unsupervised Learning, Recommenders, Reinforcement Learning, plus the Machine Learning Specialization. **How do new listings get recommended?** A content-based model scores them from their attributes until they have bookings. ### Billing Anomaly Detection URL: https://humzariaz.me/projects/billing-anomaly-detection/ Category: Applied Machine Learning Stack: Python, scikit-learn, Pandas, AWS Lambda, MySQL, Laravel A review queue for billing: the system learns what normal invoices look like, flags the odd ones, and explains why, so people only check what needs checking. Machine learning that spots unusual invoices for review before they go out, without needing past examples of errors. #### Context Billing errors were caught either by checking everything by hand or by fixed rules that missed new kinds of mistakes. There were no labeled examples of bad invoices to train on. #### Goals - Flag unusual invoices without needing labeled data. - Compare each invoice with others like it, not with the whole business. - Explain every flag so reviewers can act quickly. #### Role I designed and built the unsupervised pipeline in Python with Pandas and scikit-learn, the scoring Lambda on AWS, and the review queue integration in Laravel backed by MySQL. #### Problem There were no labeled examples of bad invoices. Reviewers either checked everything by hand or relied on fixed rules that missed new kinds of mistakes. #### Solution Built an unsupervised pipeline in Python: features per invoice, k-means to segment normal billing behavior, and a per-cluster Gaussian anomaly score with a threshold tuned on a small reviewed sample. A Lambda scores new invoices and Laravel shows flagged ones in a review queue. #### Architecture - **Feature extraction:** Per-invoice features such as line counts, amounts, codes used and timing, scaled consistently. - **k-means segmentation:** Groups invoices into segments of normal behavior so different practices are compared fairly. - **Gaussian density score:** A per-segment Gaussian model scores how unusual each invoice is; scores below a threshold are flagged. - **Scoring Lambda and review queue:** New invoices are scored on AWS Lambda; flagged ones appear in a Laravel review queue with the features that stood out. #### Decisions and trade-offs - **Unsupervised instead of waiting for labels.** Trade-off: Thresholds need human calibration, but the system can start without a labeled history. - **Cluster first, then score.** Trade-off: An extra model to maintain, but whole segments are no longer flagged just for being different. - **Human review, not auto-blocking.** Trade-off: Flags still need a person, but no invoice is held back by the model alone. #### Highlights - Applies k-means clustering and Gaussian anomaly detection from Unsupervised Learning, Recommenders, Reinforcement Learning. - Built with the Python, Pandas and scikit-learn workflow from Machine Learning with Python. - Explanations that point reviewers to the unusual features. #### Challenges - With no labels, the threshold was set against a small set of invoices reviewers had already checked, then revisited as feedback came in. Resolution: The threshold was set against a small reviewed sample and is revisited as reviewer feedback accumulates. - Different practices bill very differently, so one global model flagged whole segments; clustering first kept comparisons fair. Resolution: Segmenting with k-means before density scoring keeps comparisons within similar billing patterns. - Every flag needed an explanation, so the queue shows which features were furthest from the cluster norm. Resolution: Each flag lists the features furthest from its segment’s norm. #### Security Scoring uses invoice features, not patient notes, and the review queue follows the same billing permissions as the rest of the system. #### Performance Scoring runs per invoice in a Lambda, so the review queue fills as invoices are created without batch delays. #### Testing Synthetic anomalies injected into historical data to check they are flagged, plus stability checks on clusters between training runs. #### Results - Labels needed: None to train - Method: k-means + Gaussian - Review: Human in the loop #### Questions **Will it stop invoices going out?** No. It flags unusual invoices for a person to check; it never blocks anything on its own. **Do we need examples of past billing errors?** No. It learns what normal invoices look like and highlights the ones that do not fit. **Which certification does this apply?** Unsupervised Learning, Recommenders, Reinforcement Learning, and Machine Learning with Python. **Does it block invoices?** No. It flags them for a person to review. ### Support Ticket Routing Classifier URL: https://humzariaz.me/projects/ticket-routing-classifier/ Category: Applied Machine Learning Stack: Python, TensorFlow, XGBoost, Node.js, Redis, REST A routing model for support tickets that picks the right team and a confidence level. Two model types were compared before choosing, and low-confidence tickets stay in the shared queue. Machine learning that sends each support ticket to the right team, and leaves unsure ones for a person. #### Context Support tickets landed in one shared inbox and were sorted by whoever picked them up. Misrouted tickets bounced between teams before work started. #### Goals - Route each ticket to the right team automatically. - Compare model families fairly before choosing one. - Never route confidently when the model is unsure. #### Role I built and evaluated the TensorFlow neural network and the XGBoost model, ran the bias and variance diagnostics, and shipped the chosen model behind a Node.js REST endpoint with Redis caching. #### Problem Tickets landed in one shared inbox and were sorted by whoever picked them up. Misrouted tickets bounced between teams before anyone started on them. #### Solution Trained a softmax neural network in TensorFlow on ticket text and an XGBoost model on structured fields, compared them on the same held-out set, and deployed the chosen model behind a Node.js endpoint that returns a team and a confidence. Low-confidence tickets stay in the shared queue. #### Architecture - **Text and structured features:** Ticket text is vectorized for the neural network; structured fields such as product area and channel feed the tree model. - **Neural network (TensorFlow):** Dense layers with ReLU, L2 regularization and dropout, and a softmax output over teams. - **Gradient-boosted trees (XGBoost):** A tree ensemble trained on the same split for a direct comparison. - **Node.js API:** Returns a team and a confidence; below the threshold the ticket stays in the shared queue. Recent results are cached in Redis. #### Decisions and trade-offs - **Evaluate both model families on one held-out set.** Trade-off: More training work, but the choice rests on evidence rather than habit. - **Abstain below a confidence threshold.** Trade-off: Some tickets still need manual sorting, but confident misroutes are avoided. - **Class weights for small teams.** Trade-off: Slightly lower overall fit, but low-volume teams are not ignored. #### Highlights - Applies neural networks, softmax multiclass output, and decision-tree ensembles from Advanced Learning Algorithms. - Uses bias and variance diagnostics and learning curves from the Machine Learning Specialization. - A clear abstain path to the shared queue. #### Challenges - Some teams receive far fewer tickets, so class weights and per-class metrics kept the small teams from being ignored. Resolution: Class weights during training and per-class precision and recall during evaluation. - Training and validation curves were used to diagnose high bias versus high variance before adding data or capacity. Resolution: Training and cross-validation curves read before each change, so more data or more capacity was added only when the diagnosis called for it. - A wrong confident route is worse than no route, so the API abstains below a confidence threshold. Resolution: A confidence threshold on the softmax output; tickets below it are not routed. #### Security Ticket text is processed in the service and not written to logs; only the route and confidence are stored. #### Performance One model call per ticket behind a lightweight Node.js endpoint, with Redis caching repeat lookups. #### Testing Held-out evaluation per team, threshold tuning on a validation split, and regression tests on a fixed ticket set before each model update. #### Results - Models compared: 2 NN vs trees - Low confidence: Abstain to shared queue - Output: Softmax multiclass #### Questions **What happens when the system is not sure?** The ticket stays in the shared queue for a person to route, so uncertain tickets never go to the wrong team. **What does it save a support team?** Time spent reading and forwarding tickets by hand, so agents start on the actual problem sooner. **Which certification does this apply?** Advanced Learning Algorithms, and the Machine Learning Specialization. **What happens when the model is unsure?** The ticket stays in the shared queue for a person to route. ## Services Software, cloud and AI services for growing businesses, product teams and founders: from AI-built prototype to a reliable live product. Laravel, Node.js, Python, AWS. ### Backend and APIs URL: https://humzariaz.me/services/backend-apis/ Stack: Laravel, Node.js, MySQL, Redis The engine behind your app: logins, data, payments and integrations that stay fast when real customers show up. Everything your app does behind the screen, from saving orders to checking who can see what and talking to payment and partner systems, built so it does not slow down or break as you grow. Most products I join already have a working idea and a tired API. Endpoints grew one ticket at a time. Auth is inconsistent. A report that should be a query is a loop in PHP. I take that apart without a rewrite for its own sake. The work is Laravel or Node.js, depending on what you already run. I keep the public contract stable, then fix the model, the indexes, and the places where a request does three jobs it should hand to a queue. You get something another engineer can open in six months. Named routes, validation at the edge, and permissions that match the roles in the product, not a single is_admin flag. #### Includes - APIs (the connection points your app and partners call) with versioning, input checks, and logins that match how the product is really used. - MySQL or PostgreSQL database design, indexes, and query work aimed at pages that load in under 100ms. - Redis caching, sessions, and rate limits, so the database is not the only thing standing between you and a traffic spike. - Background jobs for email, imports, and anything slow, so customers are not left waiting on a spinner. - Safe retries for payments and webhooks (automatic notifications between systems), so a double click never charges twice. #### Outcomes - A documented set of endpoints the front end can rely on. - Slow reports replaced with indexed queries or a cached read model. - Background work that survives a deploy instead of dying with the web process. **How it starts:** We start from the workflows, not a blank schema. I map the entities, the permissions, and the slow paths, then ship a vertical slice you can call from the interface. **Good fit:** Use this when the screens exist (or are next) and you need a backend that holds up on a busy Monday. ### AWS cloud URL: https://humzariaz.me/services/aws-cloud/ Stack: EC2, Lambda, RDS, Kinesis, ALB Hosting on Amazon Web Services that stays online: servers, databases and background work that do not depend on one machine. Production hosting, not a diagram: a load balancer that spreads traffic, a database you can restore, and heavy work moved off the page your customers are waiting on. I have kept live systems on AWS at 99.9% availability: EC2 behind an application load balancer, auto-scaling, and RDS that is not a single instance you are afraid to touch. The usual shape is a web tier that stays small, Lambda or workers for anything slow, and Kinesis when events have to move as they happen. Telemetry, orders, status changes. Not a cron that hopes last night finished. I do not migrate everything in a weekend. We pick the risk that would take the product down, move that, and leave a rollback. #### Includes - EC2 servers with auto-scaling and a load balancer, set up to stay online when traffic jumps. - RDS (managed MySQL or PostgreSQL) with backups, plus read copies where reports need them. - Lambda functions and queues for work that should finish after the customer has moved on. - Kinesis streaming when events have to move in near real time instead of waiting for a nightly batch. - Private networking, firewall rules, and secret storage, so your database is never open to the internet. #### Outcomes - A deploy path that does not require SSH into one box. - A database you can restore, and a read path that does not melt the primary. - Background jobs that keep running when the web tier restarts. **How it starts:** I look at what is already deployed, what breaks when traffic jumps, and what is still on a single machine. Then we move one risk at a time. **Good fit:** Use this when the app runs on one server and now has to survive real traffic, or when AWS is already set up and nobody owns it. ### Product interfaces URL: https://humzariaz.me/services/product-interfaces/ Stack: Angular, Vue, React, TypeScript The screens your customers and staff use every day: dashboards, forms and admin tools, built in Angular, Vue or React. Interfaces people sit in all day: lists, forms, filters, and clear messages for the moments when data is slow or missing. I have shipped Angular and Vue against Laravel APIs for healthcare, rentals, food ordering, and internal CRMs. React and TypeScript when the product is new and does not already have a framework. The interface is not a coat of paint. Filters have to match the query the API can actually run. A role that cannot see a record should not get a button that 403s. Empty states are part of the work. If the design is a Figma file, I implement it. If it is a sketch and a sentence, I still ship a usable screen and we tighten it from real use. #### Includes - Angular or Vue for existing enterprise apps, React and TypeScript when the product is new. - Tables, filters, and forms that match the API instead of a static mock. - Auth-aware navigation so each role sees only what they should. - Loading, empty, and error states so the UI does not look finished only in the happy path. - Tailwind or the design system you already have, not a second visual language. #### Outcomes - A workflow a non-engineer can complete without a walkthrough. - Fewer “it works on my machine” screens, because they call the real API. - A front end the next developer can extend without rewriting the layout. **How it starts:** I pair with the API, or build both. The first screen is a real workflow, not a component gallery. **Good fit:** Use this when the backend works but the product still feels like a prototype, or when an internal tool is still a spreadsheet. ### AI features URL: https://humzariaz.me/services/ai-features/ Stack: Claude, ChatGPT, Gemini AI that removes a real manual step in your product: drafting replies, sorting requests or reading documents, using Claude, ChatGPT or Gemini. AI where it saves someone time, not a chatbot bolted onto the homepage. Each feature has clear inputs, a fallback if the AI is down, and a person who can still correct it. I have wired Claude, ChatGPT, and Gemini into rental and operations products: replies, classification, and steps that used to be a person copying fields. The useful version is boring. The model sees your data, calls your API, and a person can still correct it. If the provider is down, the product still takes the order. I will not sell you a custom model you do not need. If an API call solves the job, that is the build. #### Includes - Support or intake that drafts a reply from your own data, then a person can still edit it. - Extraction from forms, notes, or documents into fields your database already has. - Prompt and tool wiring so the model calls your API instead of inventing a status. - A path that still works when the model is slow or wrong. - Logging of what was sent and what came back, so you can see failures without guessing. #### Outcomes - One manual step removed, with a person still able to override it. - No new “AI product” that sits beside the real one. - A fallback so a provider outage is a delay, not an outage of yours. **How it starts:** We pick one job the team does by hand. I wire the model to that job, see whether it saves time, and leave the human in the loop. **Good fit:** Use this when you already have a product and want one smart step that saves your team time, not a research project. ### Database performance URL: https://humzariaz.me/services/databases/ Stack: MySQL, PostgreSQL, Redis, RDS Faster pages by fixing how your data is stored and queried, with caching where it helps. When a page is slow, the database is usually why. I find the slow query, fix how the data is organized, and stop the app from asking the same question over and over. Seven years of MySQL in Laravel apps, plus PostgreSQL where the product needed it. The pattern is the same: a report written as a loop, a missing index, a cache that was never invalidated on purpose. I read the slow log and the actual screens. Then I change the query, add the index, or move the heavy read behind Redis. RDS read replicas when the primary should only take writes. I do not “optimize” by adding hardware first. If the query is wrong, a bigger instance just hides it until the next launch. #### Includes - Slow-query review against the screens people actually open. - Composite indexes and query rewrites aimed at sub-100ms reads. - Redis caching with a clear invalidation rule, not a forever key. - Read replicas and backup checks on RDS so a restore is a drill, not a theory. - A short note on what changed, so the next person does not undo the index. #### Outcomes - Pages that waited on the database stop waiting. - A primary that is not also serving every report. - A cache you can explain, not a layer nobody dares to clear. **How it starts:** Send the slow screen or the slow endpoint. I trace it to the query, ship the fix, and show the before and after. **Good fit:** Use this when the product is live and the complaint is speed, not a missing feature. ### Real-time systems URL: https://humzariaz.me/services/realtime/ Stack: Kinesis, Node.js, WebSockets, Laravel Live updates without hitting refresh: order status, tracking and device data that appear the moment they change. Events that have to move while someone is watching: an order status, a courier location, a reading from a device. Under the hood: WebSockets, queues and AWS Kinesis. I have built Kinesis pipelines for low-latency telemetry and Node.js workers that take that stream off the web tier. The page stays responsive because it is not also the processor. For product features, that is often WebSockets or a short poll against a read model that a worker keeps current. Food ordering, rentals, health admin. The user should see the new state without reloading. Real-time is easy to demo and hard to operate. I include the dead-letter path and what happens when a consumer falls behind. #### Includes - Kinesis or a queue between the event and the work that reacts to it. - Node.js or Laravel workers that can restart without losing the stream. - A read model the UI can poll or subscribe to. - Backpressure and retries so a bad message does not stop the line. #### Outcomes - Status the user can see without refreshing. - A web tier that is not also the stream processor. - A failure mode you can see, not a silent dropped event. **How it starts:** We name the event and who needs to see it. I put a pipeline under that, then the smallest UI change that proves it. **Good fit:** Use this when your current "real-time" feature is a refresh button. ### Security and access URL: https://humzariaz.me/services/security-access/ Stack: RBAC, Auth, Encryption, Audits Make sure each person sees only what their job needs, with a record of who opened or changed what. Who can see what, and a record of who did. Fine-grained access by role (role-based access control, or RBAC), not a single admin switch. Healthcare and internal tools are where this matters. A practitioner should not open another clinic’s notes. A staff role should not export every customer. I have built that kind of RBAC on Laravel, with the checks in the API, not only hidden buttons. Encryption and audit logs sit next to the roles. If someone changes a stage, assigns a lead, or opens a record, you can say who. I treat PCI and HIPAA-style constraints as product rules: least data on the page, least data in the log, and a permission test for the endpoint. #### Includes - Role-based access on the API, with policies that match the org, not a global flag. - Audit events for the actions you would have to explain later. - Encryption for fields that should not sit in plaintext. - A pass over logs and errors so secrets and record ids are not dumped to disk. #### Outcomes - A role can be explained to a non-engineer in one sentence. - An endpoint that refuses a record the UI should not have offered. - A trail when something sensitive changes. **How it starts:** We list the roles and the records they must never see. I put those rules in the API and add a test that would fail if someone removes them. **Good fit:** Use this when access is just "logged in or not", and that is no longer enough for your clients or regulators. ### Internal tools and CRMs URL: https://humzariaz.me/services/internal-tools/ Stack: Laravel, Vue, MySQL, JIRA The admin system that replaces your spreadsheets: leads, tickets, roles, and the report someone asks for every Monday. Operations software your team lives in: pipelines, assignments, and reports, built around how your business already works. I have built CRM and CMS style apps where the value is the daily loop: a lead moves stage, a ticket is assigned, a report is exported. Laravel on the API, Vue or a server-rendered admin on the front. These tools die when they are a copy of the spreadsheet with worse search. I start from the Monday report and the status change, then build the record around that. JIRA and Postman sit in the same work. The tool has to be specified, tested, and handed to people who are not engineers. #### Includes - Pipelines, assignments, and status history. - Search and filters that match how the team already talks about the work. - Exports and the one report leadership actually opens. - Roles so a new hire does not see every account on day one. #### Outcomes - The spreadsheet is no longer the system of record. - A status change that is visible to the next person without a chat message. - A tool you can onboard someone onto in an afternoon. **How it starts:** Sit with the person who runs the sheet. I turn their columns into a model and their weekly ritual into the first screen. **Good fit:** Use this when the business runs on spreadsheets and they are starting to disagree with each other. ### Delivery and production care URL: https://humzariaz.me/services/delivery/ Stack: CI/CD, Docker, Git, Monitoring Safe, repeatable releases and monitoring, so shipping an update is routine instead of a late night. How new code reaches your live product, and how you know it is still healthy after release. Under the hood: CI/CD (automated testing and deployment), Docker, Git and monitoring. I have run CI and production monitoring on teams that ship Laravel and Node.js. Docker where the environment has to match. Git flow and review so a Friday deploy is not a surprise. The useful version is small: tests that run before merge, a deploy that does not depend on one person’s machine, and a log you can read when a job fails. I also stay for the week after. The bugs that matter show up when real data hits the new path. #### Includes - An automated pipeline that runs tests and blocks a broken change before it goes live. - Docker, so development, staging and live environments behave the same way. - Release notes and a rollback (a way back to the previous version) you have actually tested. - Logs and a simple health check that the app is up after every release. #### Outcomes - A release that is a command, not a ritual. - A staging environment that resembles production. - A first week where failures are visible. **How it starts:** I look at how you ship today. We automate the step that currently requires a person who “knows the server.” **Good fit:** Use this when releases feel risky, or the app is live and nobody is watching it. ### Health systems URL: https://humzariaz.me/services/health-systems/ Stack: Laravel, MySQL, Redis, RBAC Software for clinics and health businesses: patient records, appointments and access rules that hold up on a busy day. Software a clinic can rely on during a full waiting room. Records, appointments, and permissions that match who is allowed to see what, built with HIPAA-style safeguards (the US standard for protecting health data). Health products fail in two places: the query is too slow when the waiting room is full, and the wrong person can open a chart. I work on both. The shape is usually Laravel, a relational database, and role checks at the edge of every record. A nurse, a doctor, and a billing clerk do not share one login. I do not invent a compliance badge. I encrypt what should be encrypted, log access, and keep the path a reviewer can follow. #### Includes - Patient, appointment, and staff models with permissions that match the clinic, not a single admin flag. - Access logs for who opened a record and when. - Indexes and cache so a chart opens without a spinner. - A path for lab orders or results when that is part of the workflow. #### Outcomes - A chart the right role can open, and the wrong role cannot. - A schedule that does not double-book under two clicks. - Notes another engineer can audit without a walkthrough. **How it starts:** We start from one clinic workflow: open a chart, book a slot, or post a result. That slice ships before we widen the product. **Good fit:** Use this when your product holds patient or clinic data and the current build is a form on top of a shared table. ### AI extraction URL: https://humzariaz.me/services/ai-extraction/ Stack: Python, Claude, ChatGPT, Gemini Turn notes, messages and documents into clean data your system can store, without the AI making things up. AI that reads text and fills in the fields you already use. Every value must come from the original text, so nothing invented reaches your records. Most “AI features” are a text box. The useful version takes a clinical note, an inbox message, or a PDF and returns problems, medications, or a queue. Nothing else. I put a schema in front of Claude, ChatGPT, or Gemini. If the model invents a field, the parser drops it. If a value has no source in the text, it is not stored. The API is the product. Your screens call it. They do not talk to the model vendor directly. #### Includes - A fixed JSON schema for the fields you already have. - Rejection of keys and values the source text does not support. - A provider you can swap: Claude, ChatGPT, or Gemini. - Logs that do not keep the raw patient text. #### Outcomes - Structured fields instead of a second typing pass. - A failure mode that is “empty field”, not a made-up dose. - One endpoint your app can call. **How it starts:** You send ten real examples and the fields you need. I return the schema and a slice you can run against those examples before we wire it in. **Good fit:** Use this when someone on your team is retyping notes, sorting an inbox, or copying documents into forms. ### Partner APIs URL: https://humzariaz.me/services/partner-apis/ Stack: Laravel, OAuth, Webhooks, Postman One secure, documented connection so other companies can book, sync and receive updates from your product. A single public API (the agreed way other systems talk to yours) instead of a custom connection for every new partner. Under the hood: OAuth access scopes, signed webhooks, and a Postman collection as documentation. Integrations die when each partner gets a special route and a Slack thread. I publish a version, scopes, and a collection that matches what is live. Booking and writes are idempotent. A retry returns the original record. Webhooks fail closed when the signature does not match. v1 can stay up while v2 ships. Partners are not forced onto a new path on a Friday. #### Includes - OAuth or token scopes limited to what that partner may see. - Idempotency keys on creates. - Signed webhooks and a retry that does not double-apply. - A Postman collection and an error list that matches the code. #### Outcomes - A partner can integrate without a custom build. - A replayed request does not create a second appointment or charge. - A version you can keep stable. **How it starts:** We name the three calls a partner must make. Those ship with docs. Everything else waits. **Good fit:** Use this when another company needs to book, sync, or receive results from your product. ### Data pipelines URL: https://humzariaz.me/services/data-pipelines/ Stack: Python, AWS Kinesis, Lambda, Redis Bring in data from devices, files and imports, filter out the bad records, and keep the latest numbers ready to show. Take in data as it arrives, reject what is clearly wrong, and show the latest good value without slowing down your app. Under the hood: Python, AWS Kinesis, Lambda and Redis. Vendors post bursts. Spreadsheets arrive late. A heart rate of 0 and a duplicated row should not land next to the real ones. I put Kinesis or a queue in front, Python rules on the sample, and a small read model for the screen that asks “what is the latest.” The raw feed stays. The chart does not read it on every page load. #### Includes - Ingest that survives a burst without blocking the web app. - Rules that drop impossible or duplicate values. - A read API for the latest accepted record. - A way to replay a bad day without rewriting history by hand. #### Outcomes - A screen that shows the last good reading, not the last packet. - Imports that can be run twice. - A trail of what was rejected and why. **How it starts:** We take one feed. I write the accept rules from your real bad samples, then the read path. **Good fit:** Use this when data arrives in bursts, files, or device uploads and your product is reading the raw pile. ### Prototype to production URL: https://humzariaz.me/services/rescue-and-migration/ Stack: Laravel, MySQL, AWS, Queues Take an AI-built prototype (Lovable, Bolt, Cursor, Replit, v0) or a fragile app and make it safe, fast and ready for real customers. You have something that works in a demo. I make it work in production: secure logins, a real database, payments, hosting, monitoring, and code another engineer can maintain, without throwing away what you built. A lot of products now start in Lovable, Bolt, Cursor, Replit or v0. That is a great way to prove an idea. The gaps show up when real customers arrive: logins that are easy to get around, data stored in the wrong place, no backups, and code nobody fully understands. I keep what works and fix what will hurt you first: security, the database, payments, hosting, and the slow screens. Under the hood that usually means Laravel, Node.js or Python on AWS, with a proper database and background jobs. The same approach works for older systems: a report that takes seconds, a deploy everyone fears, or a spreadsheet acting as the database. Every move has a rollback, so the old path still works while the new one proves itself. #### Includes - A short, plain-English review of what is risky, slow, or only understood by one person (or one AI tool). - Secure logins, roles, and data handling before you take on more users. - A real database, backups, and hosting that does not depend on one machine. - Fixes for the slowest paths: indexes, background jobs, or caching. - A cutover with a way back, plus notes so the next change does not undo the fix. #### Outcomes - A product you can put in front of paying customers with confidence. - A rebuild that is smaller, or no longer needed. - A rollback you have actually tested. **How it starts:** Send a link to the prototype or describe the problem, and how to see it. I reply with what I would fix first and what I would leave alone. Pricing and scope are discussed once we know what is needed. **Good fit:** Use this when your prototype is getting real users, or your current system works until it suddenly does not and a full rebuild seems like the only idea. ### Dedicated engineer URL: https://humzariaz.me/services/dedicated-engineer/ Stack: Contract, Full ownership A senior engineer inside your team who owns a part of the product, from the data to production. I join your codebase, your board and your review process, and take ownership of a named part of the product: the API, the data, the cloud, or the interface. This is not a ticket queue. I join the repo, the board, and the review rhythm you already have. The slice I own is named: the API, the data, the cloud, or the interface. I have worked inside product teams for years. The useful part is staying long enough to own the consequences of last month’s change. I work from Lahore (UTC+5) and arrange overlap with US, UK, Europe, and Gulf hours. You get written updates a non-technical founder can read, not only a list of commits. #### Includes - A seat in your repo, your board, and your review process. - Ownership of a slice, end to end. - Production support during overlapping hours. - Written updates so a non-technical founder can see what shipped. #### Outcomes - One person who can explain the system without a meeting of three specialists. - Features that land in production, not in a branch. - A rhythm you can extend or stop after a first sprint. **How it starts:** We agree a first sprint with a named outcome, and talk through timelines and terms. If it fits, the engagement continues from there. **Good fit:** Use this when you need a senior engineer inside the team, not an agency that rotates people. ### Scoped project URL: https://humzariaz.me/services/scoped-project/ Stack: Fixed scope, Remote A clearly defined build, such as an MVP (first working version), a migration or one feature, delivered and handed over. One outcome with a clear boundary: an MVP, a move off spreadsheets, or a feature with an agreed definition of done. Then a clean handover. I take projects that can be finished. “Build the platform” is not a scope. “Replace this sheet with an app that assigns leads and exports Monday’s report” is. The stack is the one you already have, or Laravel and a front end if you are starting. I write what is in, what is out, and how we know it shipped. After delivery there is a short window for the issues that only appear with real data. Then the repo is yours. #### Includes - A written scope before the build starts. - Implementation on Laravel, Node.js, Python, or the front end you already use. - A handoff: how to run it, where the config lives, and what to watch. - A short window after delivery for the issues that only show up in real use. #### Outcomes - A thing you can log into, not a plan. - A boundary so the project does not become a second company. - Notes the next engineer can follow. **How it starts:** You send the brief. I reply with the slice I can deliver and what I need from you. We do not start on a vague build. **Good fit:** Use this when you have one project with a clear goal, not an open-ended team seat. Get in touch to discuss scope and pricing. ## Ways to work together - **Join your team** (Full-time or long contract): A senior engineer inside your team. I work in your codebase, standups and code reviews, and stay long enough to own a real part of the product. Under the hood: Laravel, Node.js, Python or AWS. - **Work solely for your company** (Dedicated contract): A dedicated engineer for one company. I take the product from planning to the live version: backend, data, hosting and screens, with your product as my focus. - **One project** (Fixed-scope project): A clearly defined build, then a clean handover: an MVP, taking an AI-built prototype (Lovable, Bolt, Cursor) to production, a migration, or an AI feature. Get in touch to discuss scope and pricing. ## FAQ ### For founders and business owners **What can I hire you for?** Building or improving the software your business runs on: web apps, the backend behind them, hosting on Amazon Web Services (AWS), and practical AI features using Claude, ChatGPT or Gemini. Most of my work has been healthcare, ordering, rental and internal business systems that have to stay fast and online. **I built my app with Lovable, Bolt, Cursor or another AI tool. Can you take it to production?** Yes. AI-built prototypes are a great way to prove an idea. I keep what works and fix what will hurt you with real customers: secure logins, a proper database, payments, hosting, backups and monitoring. A full rebuild is the last resort, not the default. **Do you take one-off projects?** Yes, when the goal is clear. That can be an MVP (a first working version), a move off spreadsheets, an API, or an AI feature. Tell me the outcome you need and I will tell you honestly whether I can deliver it. **How much does it cost?** It depends on the scope and how we work together (team seat, dedicated contract or one project). Get in touch with what you need and we can discuss scope and pricing. **Do I need to be technical to work with you?** No. I explain trade-offs in plain English and send written updates that show what shipped and what is next, so you can make decisions without reading code. ### For recruiters and hiring teams **What is your experience?** Senior Software Engineer with 7+ years in PHP (Laravel), Node.js, Python, MySQL, Angular, Vue and AWS. Domains include healthcare, rentals, food ordering, real estate, CRM and content management. The full CV is available from the Resume button. **Are you open to new roles?** I am open to roles, contracts and projects. Get in touch and we can talk about timelines. **Can you join our existing team?** Yes. I have worked inside product teams on shared Laravel, Node.js, Angular and Vue codebases, including code reviews, sprints and production support. I fit into your process rather than working beside it. **Which time zones can you overlap?** I am in Lahore, Pakistan (UTC+5) and work remotely. I schedule overlap with US, UK, Europe and Gulf teams so reviews and issues are handled live, not the next morning. ### For your tech lead **What do you actually build with?** PHP and Laravel, Node.js, Python, MySQL and PostgreSQL, Redis, Angular, Vue, React and TypeScript, and AWS (EC2, Lambda, Kinesis, RDS). AI work is API integration and applied machine learning (scikit-learn, TensorFlow), not research. **How do you handle quality and releases?** Tests that run before merge in a CI/CD pipeline, Docker so environments match, Git flow with code review, and a rollback that has actually been tried. After a release I watch logs and health checks for the issues that only real traffic exposes. **How do you approach security and access control?** Role-based access control (RBAC) enforced in the API, not just hidden buttons; encryption for sensitive fields; audit logs for actions that need explaining later; and HIPAA- and PCI-style data handling where the domain requires it. ### Getting started **How do we start?** Send a short message through the contact form: team role, dedicated contract or one project. Include what you are building, any timeline, and what “done” looks like. I reply with a concrete next step. ## Contact - Email: humzariaz47@outlook.com - Phone: +92 308 4391023 - Location: Lahore, Johar Town, Pakistan - LinkedIn: https://www.linkedin.com/in/muhammad-humza-riaz - GitHub: https://github.com/humzaxsn - Contact form: https://humzariaz.me/#contact