Saad Almubarak
Senior • Full‑stack • Product‑minded

I build modern, reliable web systems — from backend to product‑ready UI.

Strong in the Microsoft stack (.NET) and modern front‑end frameworks (including Angular) — but not limited to them.

Clean architecture, pragmatic delivery, and UX that feels effortless. This site is currently under development — I’m polishing it as I go.

Focus
Scalable backend + crisp UI
Style
Fast, clean, low‑defect delivery
Stack
ASP.NET Core • Angular • SQL
Engineering signal
0
Years building web apps (WebForms → modern .NET)
Full‑stack
C# / EF Core / APIs + Angular / TS / UI systems
Delivery
Own features end‑to‑end, ship polished & stable

Highlights

A quick snapshot of how I think, build, and deliver.

Architecture that stays clean

I design for change: clear boundaries, testable code, and maintainable patterns that scale with teams.

SOLIDClean ArchitecturePragmatic DDD

Performance & reliability mindset

I optimize the right things: latency, stability, observability, and safe migrations — without over‑engineering.

CachingEF CoreMonitoring

UI/UX that feels premium

Modern interactions, consistent systems, and attention to detail — so users feel confident and fast.

Design systemsAccessibilityMicro‑interactions

Expertise

Focused skills that matter for real delivery — not a copy‑paste list.

Backend (.NET)

  • ASP.NET Core, Web APIs, MVC/Razor Pages
  • EF Core, performance tuning, migrations
  • Auth (Auth0/Identity), secure patterns
  • Background jobs, messaging (RabbitMQ), caching (Redis)

Frontend (Angular)

  • Angular + TypeScript, scalable UI structure
  • Component libraries, Bootstrap 5, CSS/SCSS
  • State & API integration, strong UX patterns
  • Accessibility and consistent design systems

DevOps / Cloud

  • Azure & AWS basics, CI/CD, packaging
  • Docker, IIS, deployment hygiene
  • Observability: logs, metrics, tracing mindset

Engineering habits

  • Low‑defect delivery, code reviews, mentoring
  • Readable code, incremental refactors
  • Documentation that helps onboarding

Skill explorer

Click a skill to see how I typically apply it in real systems.

.NET

Backend that stays stable under change

I prefer predictable patterns: clear boundaries, explicit validation, strong auth flows, and safe EF Core migrations. I optimize where it moves the needle (queries, caching, payload shape) and keep the rest simple.

ASP.NET Core EF Core Auth0 / Identity Redis

How I work

A practical approach for shipping safely in real environments — legacy, constraints, and deadlines included.

Principles

  • Stability over cleverness — predictable code beats “smart” code.
  • Incremental change — small PRs, clear diffs, easy rollback.
  • Security by default — least privilege, safe inputs, auditability.
  • Performance with purpose — measure first, then optimize.

Delivery habits

  • Translate user stories into testable acceptance criteria.
  • Keep code review friendly: naming, structure, and clear intent.
  • Prefer reusable helpers/components over copy‑pasting.
  • Write docs that make onboarding faster (and reduce defects).

Trade‑off navigator

Pick up to two priorities — the guidance below updates like a mini system design discussion.

Maintainability

Default to clean boundaries and safe changes

Start with clear modules, boring patterns, and strong tests around critical flows. You’ll ship faster long‑term because the system stays understandable.

Clean boundaries Small PRs Refactor safely Docs that help
Case study: legacy to modern (.NET upgrade)

Problem: modernize a mature codebase without breaking production behavior.

Constraints: ongoing releases, existing integrations, and limited change windows.

Approach: incremental migration, compatibility shims where needed, and targeted performance work after stability.

Outcome: faster build/run cycle, cleaner architecture, and lower defect risk through smaller, reviewable changes.

Case study: low‑defect delivery in a release cycle

Problem: ship critical features with minimal regression.

Constraints: business deadlines, multiple contributors, and evolving requirements.

Approach: tighten acceptance criteria, prioritize critical-path tests, and keep PRs small with strong review discipline.

Outcome: fewer late-cycle defects and smoother UAT — with predictable delivery pace.

Case study: reusable UI patterns (Razor + TypeScript)

Problem: repeated UI behaviors created inconsistent UX and duplicated bugs.

Constraints: existing pages and legacy patterns had to stay stable.

Approach: build independent components/helpers with predictable initialization and minimal page coupling.

Outcome: faster feature work, consistent UX, and fewer regressions from copy‑paste edits.

How I work

Clear expectations, calm delivery, and honest trade‑offs — how I like to build with a team.

What I’m open to

  • Long‑lived web systems with real users and real constraints
  • Legacy modernization: safe migrations, predictable rollouts
  • Architecture and implementation — not just diagrams
  • Mentorship, code reviews, and raising engineering standards

What I optimize for

  • Stability over novelty
  • Small, reversible changes with checkpoints
  • Interfaces and contracts that survive upgrades
  • Low‑defect delivery (tests, monitoring, and disciplined reviews)

What I’m not optimizing for

  • Big‑bang rewrites without measured risk
  • “Just ship it” culture with no accountability
  • Hype‑driven tech choices that make maintenance harder
  • Complexity just to look advanced

How I keep projects moving

1
Clarify constraints early
Before coding: scope, dependencies, edge cases, and what “done” means.
2
Ship the smallest safe slice
Feature flags, incremental rollout, and compatibility by default.
3
Make the system easier tomorrow
Refactor with intent, document decisions, and leave a clean path for the next engineer.

Engineering Decisions

Short notes from real engineering work — what I chose, what I avoided, and why.

Why I avoided over-abstracting a reusable checklist component Component design • Maintainability

Context: Large .NET system with an admin-configured feature that must be embedded on any page via a simple tag/element — reuse needs were still evolving.

Decision: Ship a focused, independent component with clear extension points instead of a “framework”.

Why: Premature abstraction increases cognitive load, slows onboarding, and tends to lock in the wrong API.

Outcome: Faster adoption, safer iteration, and a clearer path to refactor once usage patterns stabilize.

Deeper note: I kept the surface API small (config + render hook) and pushed optional behaviors behind feature flags so we can expand without breaking existing pages.

Why I optimized for backward compatibility instead of redesign Delivery • Risk control

Context: Existing pages and behaviors depended on stable contracts, with tight release windows.

Decision: Prefer incremental improvements and compatibility guarantees over a full redesign.

Why: Stability builds trust; breaking changes multiply downstream work and increase production risk.

Outcome: Smooth rollout with minimal disruption and a stronger baseline to modernize gradually.

Why I kept UI-specific logic close to the view instead of over-splitting services Readability • Ownership

Context: Some behaviors were tightly coupled to view state and not broadly reusable.

Decision: Keep the logic local, extract only when patterns repeat across modules.

Why: Over-engineering hurts readability and increases the “where is this handled?” tax.

Outcome: Clearer flow, fewer files to chase, and easier maintenance for the next engineer.

Why I prefer small, reversible refactors over big-bang rewrites Refactoring • Quality

Context: Enterprise systems often have hidden dependencies and long-lived edge cases.

Decision: Refactor in safe slices with measurable checkpoints.

Why: Reversible changes reduce risk, keep stakeholders confident, and make regressions easier to isolate.

Outcome: Better outcomes with fewer surprises — and improvements that stick.

Resilience

Things break. Here’s how I recover fast, keep people calm, and stop the same class of issue from repeating.

The “works on my machine” deployment trap

CI/CD • Config • Observability

What happened: A release behaved differently in production because one environment value wasn’t aligned with the expected defaults.

Recovery: Reproduced with production-like config, added a validation check at startup, and documented the required settings.

What changed: Safer deployments, fewer “mystery” incidents, and faster rollbacks when needed.

A “small” refactor that broke an edge case

Refactoring • Regression • Testing

What happened: A cleanup improved readability but missed a rare path that only appears with specific data shapes.

Recovery: Added a targeted unit test, restored the missing behavior, and kept the refactor in smaller reversible slices.

What changed: Better guardrails and a repeatable approach to safe refactoring.

UI regressions after a library upgrade

Frontend • Bootstrap • Compatibility

What happened: Upgrading UI dependencies caused layout shifts and behavior changes in a few critical screens.

Recovery: Isolated changes behind a feature toggle, fixed the highest-risk pages first, then completed the upgrade with a regression checklist.

What changed: Upgrades became predictable instead of disruptive.

My recovery checklist

Playbook

  • Reproduce with the closest environment + data shape
  • Reduce to a minimal failing case
  • Fix + add a test (or monitoring) that prevents the same failure class
  • Document the decision in the Decision Log
  • Ship the smallest safe change, then iterate

Design Lab

A small system‑design sandbox. Pick constraints and I’ll show the trade‑offs I’d argue for in a real review.

Constraints

Team / Org
Medium
Weekly

This is intentionally lightweight: it demonstrates trade-off thinking without pretending every system is the same.

Recommendation

Deep review: This simulator intentionally starts with a modular monolith. The split-to-services rule is conservative to avoid “architecture theater.” In real work, I validate split points with operational data (deploy frequency, ownership boundaries, failure domains).

Suggested shape


            

Trade-offs

    What I ship

    The kind of work I’m comfortable owning end‑to‑end.

    Enterprise-grade web platforms

    Modular systems, clean boundaries, and predictable delivery — built to survive years of change.

    ModularityMigrationsPerformance

    Identity & security workflows

    Real-life auth, metadata, roles, and safe flows that balance security with a smooth user experience.

    AuthRBACAuditability

    Dashboards & operations UI

    Fast, readable interfaces for real data — with consistent components and practical visualizations.

    UI systemsTypeScriptA11y

    Work themes

    The kind of problems I like solving — the ones that need both engineering depth and product thinking.

    Enterprise platforms

    Complex domains, lots of data, real users. I focus on clean boundaries, safe changes, and performance where it matters.

    Domain modelingEF CoreMigrations

    Identity & security

    Auth flows, least‑privilege access, and defensive coding — built into the system, not bolted on.

    Auth0Secure patternsAuditing

    IoT dashboards & telemetry

    Real‑time readings, resilient pipelines, and UI that stays readable under pressure.

    MQTTCachingMonitoring

    Systems Stability Challenge

    Keep the system stable for 20 seconds by balancing caching, retries, and throttling.

    How it works

    Traffic changes automatically. Your job: keep Errors low without pushing Latency too high. Use the sliders — the chart shows your stability over time.

    Quick tips
    • Caching reduces backend load.
    • Retries may lower errors, but can amplify load.
    • Throttling protects stability but increases queueing.
    Stability
    Latency
    Errors
    Traffic
    Ready.
    No hover gimmicks here — only the simulation.

    Looking ahead

    I’m always sharpening the craft: better systems, better UX, better delivery.

    More product impact

    I enjoy owning outcomes: understanding users, shipping value, and improving the system continuously.

    Modern DevOps

    CI/CD polish, observability, and resilient deployments — so delivery is safe and repeatable.

    AI‑assisted workflows

    Careful use of AI to speed up boring parts while keeping code quality and security strong.