Skip to content
Mohamed Saeed

Backend Engineer · Riyadh, Saudi Arabia

Payments, queues,and query plans.

I'm Mohamed Saeed Bin Omar, a backend engineer in Riyadh. Two years of production work in TypeScript/NestJS and C#/ASP.NET, most of it on the parts of a system where being wrong is expensive: payment integrations, background jobs that must not run twice, and database schemas that have to stay fast as the tables grow.

Now
Backend Engineer, Clean Life — Riyadh
Core stack
TypeScript · NestJS · PostgreSQL · C# · ASP.NET Core
Languages
Arabic (native) · English (professional)
Work authorisation
Saudi Iqama — Software Engineer, transferable
01

What I work on

Six areas, each with shipped production work behind it. The technologies underneath are context, not a ranking.

  • 01

    APIs and service boundaries

    REST APIs and the services behind them: module boundaries, validation and DTO layers, versioning, and error responses a client can act on. Access control belongs at the boundary too — JWT and OAuth2 flows, role- and policy-based rules, rate limiting — so that individual features never have to reinvent it.

    • NestJS
    • ASP.NET Core
    • Express
    • FastAPI
    • JWT
    • OAuth2
    • RBAC
    • PBAC
  • 02

    Data modelling and query performance

    Schema design, indexing, and finding the query that is quietly costing the most. Most of the latency I have removed from a system came out of the data layer rather than the application code — a missing index, a relation loaded row by row, a table shaped for writing and then read in a completely different way.

    • PostgreSQL
    • SQL Server
    • Redis
    • MongoDB
    • TypeORM
    • Prisma
    • Indexing
  • 03

    Background jobs and async work

    Queues, retries, distributed locks and scheduled work. Running a job is the easy part. The work is making sure it runs exactly as often as it should, that two workers never pick up the same unit of work, and that a failure overnight does not need a person awake to handle it.

    • BullMQ
    • Redis
    • Idempotency
    • Distributed locking
    • Dynamic scheduling
  • 04

    Payments and third-party integrations

    Card charges, hosted payment links and refunds against the Tap gateway, and field service data through Zoho FSM. Integration work is mostly failure paths: signed webhooks, an audit trail you can reconstruct a dispute from, and retries that never charge someone twice.

    • Tap
    • Webhooks
    • HMAC signing
    • Zoho FSM
    • Audit logging
  • 05

    Code review and delivery

    I run code review for the backend team and plan sprints with our technical lead, at roughly 45 tasks per two-week cycle. Review is where risky migrations, N+1 queries and missing indexes get caught while they are still cheap. Generated code gets read more carefully than hand-written code, not less.

    • Code review
    • CI/CD
    • Docker
    • Jest
    • Zoho Sprints
  • 06

    LLM-backed features

    Running models locally where a network connection cannot be assumed, and building against hosted APIs where it can. The interesting constraints are usually not the model — they are latency, cost per call, and what the product does when the model returns something unusable.

    • LangChain
    • Local model hosting
    • Gemini API
    • FastAPI
02

Experience

  1. Dec 2024PresentRiyadh

    Backend Engineer · Clean Life Company

    Clean Life runs its field service operations on a platform built around Zoho FSM. I work on the backend behind it — the data layer, the payment integration, and everything that runs outside the request cycle. Since December 2025 I also lead code review and technical coordination for the backend team.

    • Re-architected the FSM-integrated backend — a PostgreSQL schema redesign, indexing, caching, and moving heavy work onto BullMQ queues — and brought data-retrieval latency down by around 90%.
    • Built the payment service on the Tap gateway, putting card charges, hosted payment links and refunds behind one interface the rest of the platform calls into.
    • Unified background processing on BullMQ with retry handling, added a Redis caching and locking service with standardised keys, and an audited webhook service. Job failures dropped and the race conditions we had been seeing stopped.
    • Wrote a scheduled-job service that registers and reschedules jobs at runtime without restarting the server, and logs every run.
    • Run code review for the team, with particular attention to generated code, catching risky migrations, N+1 queries and missing indexes before they merge. Plan sprints with the technical lead at around 45 tasks per two-week cycle.
    • TypeScript
    • NestJS
    • PostgreSQL
    • Redis
    • BullMQ
    • TypeORM
    • Docker
    • Tap
    • Zoho FSM
    Read the case study
  2. Jun 2024Dec 2024

    Backend Developer · ASAS Software Foundation

    Worked on ASAS ERP, building the REST APIs behind its business modules on ASP.NET Web API and SQL Server.

    • Built and maintained the REST API surface the ERP's clients were built against.
    • Rewrote the reporting endpoints behind more than ten business reports and cut their load times.
    • C#
    • ASP.NET Web API
    • SQL Server
03

Selected work

Six projects, chosen because each shows a different dimension: performance work, money-critical integration, product, developer experience, and building under hard constraints.

Case study · Clean Life · production

2025

Field service platform backend

The backend behind Clean Life's field service operations, integrated with Zoho FSM.

Problem

Reads had become the bottleneck. The schema had grown around what was convenient to write rather than what the product actually read, and every request paid for that at the moment a user was waiting.

Approach

Redesigned the PostgreSQL schema around the real read paths, added the indexes those paths needed, put a Redis cache in front of the results that could tolerate it, and moved everything that did not have to happen inside the request onto BullMQ queues.

Outcome

Data-retrieval latency came down by around 90%, and the work that used to make requests slow now runs on queues where a failure is retried instead of surfaced to a user.

The clearest example of how I approach a performance problem: measure first, change the data model before the code, and move work out of the request path rather than making it faster in place.

  • NestJS
  • TypeScript
  • PostgreSQL
  • Redis
  • BullMQ
  • TypeORM
  • Zoho FSM
  • Clean Life · production

    2025

    Payments service on Tap

    One service owning every path money takes through the platform.

    Problem

    Card charges, hosted payment links and refunds are three different flows with three different failure modes, and each part of the platform that needed one was in a position to get it subtly wrong.

    Approach

    Put all three behind a single interface, so callers describe what they want to happen rather than how to talk to the gateway. Gateway callbacks arrive through a signed webhook service that records every event it accepts, which makes a payment reconstructable after the fact.

    Outcome

    Payment behaviour lives in one place, and the audit trail means a disputed transaction is a question with an answer rather than an investigation.

    • NestJS
    • TypeScript
    • Tap
    • Webhooks
    • HMAC
    • PostgreSQL
  • Open source · pull request dashboard

    2025

    Gitify

    A dashboard that organises GitHub pull requests by base branch and by the stacks they form.

    Problem

    GitHub's own list view flattens stacked pull requests, so the one thing you need to know — what has to merge before what — is the one thing it does not show.

    Approach

    Stacks are inferred rather than declared: when one pull request's base branch is another's head branch, the first is treated as a child of the second. That gets rendered as both a tree and an SVG dependency graph. Auth is a GitHub App flow where the access token stays in memory, the refresh token is an HttpOnly cookie scoped to the auth routes, and concurrent 401s collapse into a single refresh.

    Outcome

    A stack is visible without anyone maintaining metadata about it, and a token never reaches browser storage.

    • Next.js
    • TypeScript
    • TanStack Query
    • Zustand
    • Tailwind CSS
    • GitHub API
  • 2025

    NestJS · Fastify · Prisma starterOpen source · project template

    The service skeleton I keep reaching for, written down properly.

    • NestJS
    • Fastify
    • Prisma
    • PostgreSQL
    • Zod
    • Winston
    • Docker
  • 2024

    JaberahShipped product · mobile and API

    An app for managing mosque student records and activities.

    • Flutter
    • ASP.NET
    • C#
    • SQL Server
  • 2024

    Offline Python coding assistantGraduation project

    A code assistant for students whose internet connection cannot be relied on.

    • FastAPI
    • LangChain
    • Local LLM
    • React
    • Express
04

Credentials

Education

  • B.Sc. Computer Science, with honours

    Hadhramaut University · 2021 — 2024

Certifications & memberships

  • Saudi Council of Engineers — Specialist (Computer Science)

    SCE membership · 2026

  • Microsoft Back-End Developer Professional Certificate

    Coursera · 2025

Teaching & volunteering

  • Backend development trainer

    Hadhramaut University · 2023

    Taught ASP.NET Core — MVC, REST APIs and EF Core — to more than twenty students.

05

Contact

Open to backend and platform roles in Saudi Arabia and remote, and to focused contract work.