Skip to content
Mohamed Diaa, back to top

Full-Stack Software Engineer · Backend Focus

Mohamed Diaa Eldin

Full-stack software engineer with 3+ years of experience, focused on backend systems for multi-tenant commerce: sales-channel and ERP integrations, queue-based processing, performance and production reliability. I work mainly with TypeScript, NestJS, PostgreSQL, Redis and React/Next.js.

  • Cairo, Egypt
  • 3+ years of experience
  • Currently at Juthor
View case studies Email me Resume (opens in a new tab) LinkedIn (opens in a new tab)

I own problems from start to finish. I find the root cause in logs and data, weigh the options on cost, risk and team readiness, explain the trade-offs to stakeholders, and turn the decision into a clear plan the team can deliver. I like automating repetitive work, and I build AI-assisted tools my team uses every day.

Key results

Experience

Professional experience

An overview of my responsibilities and contributions in each role. The case studies that follow cover the most significant work in depth.

  1. Software Engineer (Full-Stack, Backend Focus) · Juthor

    Jul 2025 – Present

    Saudi Arabia, remote. A Saudi omni-channel commerce platform that lets merchants manage products, orders and stock across many sales channels, such as Noon, Salla, Jahez and Trendyol, from one dashboard.

    Integrations and full-stack delivery

    • Built and maintain integrations with TheChefz, HungerStation, Trendyol, PIK and the STAX ERP, and contributed to the Jahez and Salla integrations, using REST APIs, webhooks and data mapping.
    • Work with partner integration teams on API contracts, expected behaviour and integration issues.
    • Deliver full-stack features across NestJS and Next.js, such as sound alerts for new orders and bilingual English and Arabic invoices.
    • Set up an Nginx proxy that routes requests from developers' local machines to a partner's testing sandbox, which only accepted a few whitelisted IPs. Developers no longer had to wait for new IPs to be approved.

    Performance and production reliability

    • Cut a business-critical order-processing workflow from 3.5–10 seconds to 0.5–0.9 seconds.
    • Built a rate-aware queue system that keeps high-volume bulk operations within each channel's limits.
    • Refactored a fragile order-handling flow by responsibility, which sharply reduced regressions.
    • Monitor production in Datadog, investigate critical issues, and write incident reports that show the business impact.
    • Built a reporting foundation for a business analytics dashboard that loads in about 100–150 ms.

    Architecture, planning and stakeholders

    • Research solutions, document their pros and cons, and present the options to stakeholders.
    • Compared refactoring options for a core domain, chose Domain-Driven Design in a modular monolith with hexagonal architecture, and wrote an RFC to gather developer feedback.
    • Researched migration strategies and proposed the strangler fig pattern, so the team refactors one business boundary at a time without stopping feature work.
    • Write product requirements and turn decisions into Jira plans that show what runs in order and what runs in parallel.
    • Led requirements gathering with product leadership for the analytics dashboard.

    Engineering quality and team enablement

    • Built multi-agent AI code review and automation tools with Claude Code, Codex and OpenCode, and helped the team adopt them.
    • Added CI checks that enforce Domain-Driven Design rules, such as domain ownership and the import direction between the application and infrastructure layers, and sped up build and test runs.
    • Designed a development workflow that fits the team, from ticket planning to review.
    • Write unit, integration and end-to-end tests, help QA with test cases, and run sessions on database performance and Domain-Driven Design.
    • Worked with product and the team lead to cut repetitive follow-up on open pull requests, and built a small tool that shows each person what is waiting on them.

  2. Software Engineer · Vultara, Inc.

    Aug 2024 – Jul 2025

    United States, remote. Promoted from Junior Software Engineer after 7 months, in Feb 2025. A US automotive cybersecurity platform that automates threat analysis and manages vulnerabilities and software bills of materials (SBOM) for ISO/SAE 21434 compliance.

    Features and integrations

    • Delivered full-stack features for threat modeling, vulnerability management, dashboards and third-party integrations using Angular, Node.js, Express and MongoDB.
    • Unblocked a delayed third-party integration despite outdated vendor documentation.
    • Built SBOM (software bill of materials) import and export in the CycloneDX standard by studying the specification and mapping our internal data model to it.
    • Proposed UI libraries for a canvas-heavy feature to the CTO and engineering managers, and adopted them.

    Performance and code quality

    • Improved selected workflows by up to 90%, including a legacy algorithm rewritten to run in O(n) and slow reports fixed.
    • Found critical bugs before customers did and shipped fixes after agreeing the plan with managers.
    • Reviewed teammates' code after my promotion, and wrote unit tests and CI checks in a regulated domain.

    Customers, stakeholders and team

    • Gathered requirements in customer meetings and with security specialists, UX engineers and management.
    • Improved onboarding for new joiners, coached a junior developer on tree-traversal performance, and joined hiring interviews as a shadow interviewer.

  3. Freelance Software Engineer · Fiverr and direct clients

    2021 – 2022

    Remote, in my final university year, before AI coding assistants. Solving problems from documentation, experiments and debugging taught me to learn fast and work with unknown systems.

    • Built a face-recognition proof of concept for a client in Saudi Arabia, and packaged it with Docker.
    • Automated database backups and heavy operations for a university ERP in Egypt, and sped up its heavy database work.
    • Delivered a small-scope integration with an undocumented legacy system for a university in the Netherlands.
    • Coached a developer on a legacy team in JavaScript and in learning from official documentation.

Case studies

Selected engineering work

A closer look at key projects: the challenge, the options considered, the decision and the outcome. Company and client details are kept general for confidentiality.

Show

Showing 14 case studies

Business and customer impact

Rate-Aware Queue System for Partner Integrations

Juthor
  • NestJS
  • Redis
  • BullMQ
  • PostgreSQL

Problem: Bulk operations could outpace partner APIs, each with its own rate limits, and blind retries turned those limits into a flood of failed calls.

Impact: Bulk updates now reach sales channels reliably, the failed-call flood stopped, and the system runs in production within the existing budget.

Read the full case study for Rate-Aware Queue System for Partner Integrations

Options: Add a new message broker, or build on the Redis already in our stack. With a tight infrastructure budget, I chose Redis and BullMQ and borrowed load-levelling ideas from Kafka and Azure architecture guidance.

What I did
  • Designed buffering, a token-bucket rate algorithm with one shared budget per partner account, bounded workers, clear retry rules and fair scheduling across merchants.
  • Made limits configurable per partner and verified the result in production monitoring after release.
  • After the architecture was agreed, defined clear module boundaries and a PostgreSQL-backed event delivery engine using the outbox pattern, and split the work into gated phases and Jira tasks.

Order-Handling Flow Refactor

Juthor
  • NestJS
  • PostgreSQL
  • Clean code

Problem: The flow that accepts or rejects incoming orders had a regression problem: almost any change broke something else.

Impact: Regressions dropped sharply, the flow became easier to change, and the whole team understands how it works.

Read the full case study for Order-Handling Flow Refactor

Options: Keep patching the existing code, or refactor it. Patching kept producing regressions, so I proposed a refactor.

What I did
  • Split the logic by responsibility, following the single-responsibility principle, so each part can change on its own.
  • Removed unnecessary database queries along the way.
  • Met the product manager to confirm business rules that were unclear, and documented the new structure so anyone on the team can work on it.

Production Investigations and Incident Reporting

Juthor
  • Datadog
  • SQL
  • Root-cause analysis

Problem: Production issues affecting orders, invoices and partner sync were spread across noisy logs, and the business could not see which customers were affected.

Impact: Product sees what broke and who is affected, fixes are prioritized by business impact, and several silent customer-facing bugs were fixed early.

Read the full case study for Production Investigations and Incident Reporting
What I did
  • Set up a daily production error review that groups related errors and checks a week of history before calling anything new.
  • Traced each issue through the full request lifecycle and wrote incident reports for Engineering and Product, with the business impact per customer.
  • Separated genuine partner-side rejections from our own defects, and found silent data-sync bugs, such as ID collisions between products and variants, before customers reported them.
  • Explained the cost and customer impact of each issue to the business to agree on fixes, and turned the investigation steps into a reusable workflow.

Business Analytics Dashboard and Reporting Foundation

Juthor
  • PostgreSQL
  • NestJS
  • Next.js
  • Background jobs

Problem: Partners who run many brands and locations could only see one brand at a time. Leadership needed one view of orders, revenue, profit and loss, operating costs and stock capacity across all of them.

Impact: Reports load in about 100–150 ms across locations and channels, the numbers stay correct as orders change, and the foundation is reused for new reports.

Read the full case study for Business Analytics Dashboard and Reporting Foundation

Options: Query every brand's data live for each chart, read from a replica, or pre-aggregate the data. Live queries meant hundreds of queries per page load and could not meet the response target, so I chose pre-aggregated reporting tables, with a read replica for detail views.

What I did
  • Met the CEO and product team to review the charts they wanted, researched the right equations, and agreed the formula behind every number.
  • Grouped the dashboard into four tabs, Overview, Money, Operations and Stock, plus a summary strip of brands, products and locations.
  • Built the charts on top of it: marketplace performance, top locations and brands, revenue trend against the previous period, revenue concentration (Pareto), an order status funnel, fulfillment time, orders over time with a 7-day moving average, an hour-by-weekday heatmap, and service-level adherence.
  • Added stock views: an item performance table with ABC classification, days of stock left and stock status, and an alert table for brands with stock outages.
  • Built time-bucketed tables keyed by date and hour. Switched the refresh job from a fixed time window to change tracking, because orders that changed status later were being missed.
  • Defined each metric once, so the fast path on the reporting tables and the live fallback always give the same answer, and handled local time zones so every day starts at the right hour.

Unblocking an Undocumented Third-Party Integration

Vultara
  • Node.js
  • REST APIs
  • Browser DevTools

Problem: We supported several versions of a third-party API, but its documentation was outdated and its support was slow. The delay put a customer release and timeline at risk.

Impact: Closed the gap that was blocking the release and protected the timeline agreed with customers.

Read the full case study for Unblocking an Undocumented Third-Party Integration

Options: Wait for a meeting with the vendor, search their developer support pages, or study the real traffic. Waiting would miss the timeline, and the support pages had nothing, so I studied the traffic.

What I did
  • Worked out the real request patterns with browser DevTools and implemented the missing part of the integration.

Platform and engineering depth

Domain-Driven Modular Monolith: Architecture, Migration Strategy and RFC

Juthor
  • Domain-Driven Design
  • Hexagonal architecture
  • Modular monolith
  • Strangler fig
  • RFC

Problem: Core business rules were spread across many services, and the same tables were written from many places, so changes were risky.

Impact: The team agreed on one clear direction and a safe way to get there: changes are safer today, feature work continues during the migration, and the door stays open to microservices later.

Read the full case study for Domain-Driven Modular Monolith: Architecture, Migration Strategy and RFC

Options (architecture): Refactor so each table has one owning module that writes to it, split the logic up, or refactor toward single-responsibility domain logic with a hexagonal architecture. I compared the pros and cons of each against developer experience and knowledge, findings from current code reviews, and the tech team's plan to move to microservices later. Domain-Driven Design in a modular monolith with hexagonal architecture fit all of these best.

Options (migration): The existing system was organized horizontally by technical layer, while Domain-Driven Design is vertical, organized by business area. I researched several refactoring strategies and documented the pros and cons of each. The strangler fig pattern matched best, because it replaces the old code one business boundary at a time while the system keeps running.

What I did
  • Mapped every entry point and background workflow that changes the domain.
  • Discussed the options with the engineering and product teams, then wrote an RFC (request for comments) so every developer could review and comment.
  • After agreement, planned the refactor around business boundaries using the strangler fig pattern.
  • Ran sessions to align developers on the chosen approach.

SBOM Import and Export in CycloneDX

Vultara
  • Node.js
  • MongoDB
  • CycloneDX
  • Data mapping

Problem: Customers needed to exchange software bills of materials (SBOMs) with other tools in a standard format, both into and out of our platform.

Impact: Customers could import and export SBOMs in a widely used standard, which made the platform easier to use alongside their other security tools.

Read the full case study for SBOM Import and Export in CycloneDX
What I did
  • Read the CycloneDX and SBOM documentation to understand the standard and its purpose.
  • Studied our internal tables and designed how each part of our data maps to the standard in both directions.
  • Built the import and export features on top of that mapping.

Legacy Calculation Engine Rewrite

Vultara
  • Node.js
  • Algorithms
  • Unit testing

Problem: A partly built feature collects data from several sources and runs cybersecurity calculations. The legacy algorithm it reused had very high complexity, and a typical run took about 15 minutes.

Impact: A linear-time calculation with the same results and no regressions, so the feature could be extended safely.

Read the full case study for Legacy Calculation Engine Rewrite

Options: Build on top of the legacy code as it was, or rewrite it with strong tests. Extending it would carry the slowness forward, so I recommended a tested rewrite and agreed it with the team.

What I did
  • With no time to read the whole book, learned the key ideas of Working Effectively with Legacy Code through summaries and podcasts, then wrote black-box tests that lock in the current behaviour.
  • Rewrote the algorithm to run in O(n) and covered both the legacy and new paths with unit tests.

Report Performance and Timeout Fixes

Vultara
  • Node.js
  • MongoDB
  • Performance profiling

Problem: Some report flows failed with gateway timeouts, and that part of the system had little logging or metrics.

Impact: Faster reports for customers, proven with before-and-after timings measured on UAT with the SRE team.

Read the full case study for Report Performance and Timeout Fixes
What I did
  • Traced the flow, found the expensive algorithms, and added timing hooks to measure execution under different scenarios.
  • Optimized the queries, added indexes, fetched only the needed fields, and ran independent queries in parallel.

Team productivity

AI-Assisted Code Review and Automation

Juthor
  • Claude Code
  • Codex
  • OpenCode
  • Bash
  • Sub-agents

Problem: Code reviews and PR follow-up took a lot of repeated manual effort, and one general AI review pass gave uneven results.

Impact: Reviews are faster and more consistent, and the team spends less time on repetitive tasks.

Read the full case study for AI-Assisted Code Review and Automation

Options: Keep reviews fully manual, run one general AI review, or split the work between fixed scripts and focused AI agents. I chose the split, so the predictable steps always run the same way.

What I did
  • Built a review command with a deterministic part and an AI part. A Bash step measures the PR size and changed code, then decides how many reviewer sub-agents to run.
  • Each sub-agent checks one area: architecture rules, engineering rules, the ticket requirements, or regressions. Follow-up reviews confirm that earlier comments were really fixed.
  • A human stays in the loop: a reviewer checks the AI findings, removes repeated or wrong ones, validates the rest, and adds more reviewers when needed.
  • Used the same pattern for rebasing PRs, PR triage and production investigations, and helped teammates adopt the tools.

Faster Onboarding for New Joiners

Vultara
  • Mentoring
  • Knowledge sharing

Problem: New joiners felt overwhelmed by scattered onboarding materials and complex features.

Impact: New joiners found materials easily, felt less overwhelmed, and finished their first tasks faster.

Read the full case study for Faster Onboarding for New Joiners
What I did
  • Proposed a single onboarding page that links to every existing material.
  • Asked new joiners to vote on their top blockers from three options, then scheduled short sessions on the most common one, inviting more experienced colleagues to lead topics they knew best.

Freelance: final university year, before AI coding tools

Face-Recognition Proof of Concept

Client in Saudi Arabia
  • Python
  • Flask
  • Docker
  • Open-source AI libraries

Problem: A client wanted to compare a person's face against existing faces using AI, and needed a working prototype.

Impact: The client got a portable proof of concept that ran the same on any machine, and I gained Docker as a lasting skill.

Read the full case study for Face-Recognition Proof of Concept

Options: Compared several open-source face-recognition libraries on accuracy and developer experience, ran tests, and agreed the choice with the client.

What I did
  • Wrapped the chosen library in a Flask API that matches new faces against stored ones.
  • Hit OS differences a Python virtual environment could not solve, so I learned Docker and its networking quickly and shipped the backend as a Docker image.

University ERP Automation

Client in Egypt
  • Bash
  • Python
  • SQL
  • Database administration

Problem: A confidential ERP used by many private universities had slow manual operations and heavy database work.

Impact: Routine operations ran automatically, heavy database work became lighter, and the team gained frontend capacity.

Read the full case study for University ERP Automation
What I did
  • Wrote Bash and Python scripts to automate database backups and to run heavy operations at low-load times.
  • Researched newly released database features and moved heavy logic in client-specific features into database configuration, so the database handles it. This meant less code and faster operations.
  • Wrote a Python script to migrate CSV-based data into a relational database, and coached a teammate in JavaScript so he could help with the frontend.

Integration with an Undocumented Legacy System

Client in the Netherlands
  • JavaScript
  • REST APIs
  • Browser DevTools

Problem: A university needed a small-scope integration with its legacy backend, with no source code, no documentation and no one to explain the contract.

Impact: A working integration without any access to the legacy code. When the client later reported an edge-case bug, I fixed it during a short call.

Read the full case study for Integration with an Undocumented Legacy System
What I did
  • Learned browser DevTools, then used a university account to trace each request: endpoints, parameters, bodies and behaviour in different scenarios.
  • Rebuilt the API contract from what I observed and built the integration.

Skills

Technical skills

Core stackHighlighted skills are the ones I use most.

Languages

  • TypeScript
  • JavaScript
  • SQL
  • Python
  • Bash
  • Java and Spring Boot (familiarity)

Backend

  • Node.js
  • NestJS
  • Express
  • REST APIs
  • Webhooks
  • gRPC
  • Flask

Frontend

  • React
  • Next.js
  • Angular
  • Tailwind CSS

Data and messaging

  • PostgreSQL
  • Redis
  • BullMQ
  • MongoDB
  • query optimization
  • indexing
  • read replicas

Architecture

  • Domain-Driven Design
  • modular monolith
  • event-driven systems
  • outbox pattern
  • multi-tenancy
  • rate limiting

Tools and testing

  • Docker
  • Linux
  • Git
  • GitHub Actions
  • Jenkins
  • Datadog
  • Nginx
  • Jira
  • Jest
  • Vitest

AI-assisted engineering

  • Claude Code
  • Codex
  • OpenCode
  • multi-agent code review
  • workflow automation

How I work

From problem to delivery

A consistent approach that runs through the case studies above.

  1. Find the root cause

    I investigate logs and data first, so each fix addresses the real problem and its business impact is understood.

  2. Compare the options

    I research alternatives and document their pros and cons against cost, risk, team readiness and timeline.

  3. Agree with stakeholders

    I present the trade-offs to product and leadership, and publish an RFC for engineering feedback.

  4. Plan the delivery

    I break the decision into Jira tasks with clear dependencies: what runs in sequence and what can run in parallel.

  5. Automate the repetitive

    I build scripts and AI-assisted tools, with a human in the loop, so the team can focus on higher-value work.

Education and more

Education

Bachelor of Management Information Systems

Higher Institute of Advanced Studies, Cairo

2018 – 2022

Graduated with Excellent Honors

Certifications

  • Full-Stack Web Development Nanodegree

    Udacity · 2022

  • MySQL Databases

    Meta · 2023

  • Java Programming

    Duke University · 2020

Volunteering and languages

Volunteer Python Instructor

Resala Training Centers

Built hands-on lessons and mentored students.

  • Arabic (native)
  • English (professional)

Contact

Get in touch

I am open to backend and full-stack engineering roles where I can take ownership of problems from analysis to delivery. Email is the best way to reach me.

mdiaan442@gmail.com LinkedIn (opens in a new tab) Resume (opens in a new tab)