Full-stack engineerAmman, Jordan
I’m Zaid Haddadin. At PwC Middle East I own the shared React and TypeScript application behind a large enterprise AI programme — and the work underneath it that keeps the thing honest: streaming, authentication across two runtimes, Python services, Azure storage, and the production failures that belong to none of them cleanly. I have also built and shipped two products on my own — one from my own definition, one to a written spec.
Where I work
Requirements
Interface
Integration
Services
Data & cloud
Delivery
Six layers between a requirement and a user. Most engineers own one or two. The argument of this site is that I work across all of them — and each case study says exactly how much of each was mine.
One confidential enterprise programme and two products I built alone. Each case study states its ownership boundary rather than implying one.
PwC Middle East · Enterprise programme
One application, several AI assistants, and the plumbing that makes them trustworthy
Streaming answers that stay readable while they arrive — and a conversation that is still there tomorrow.
2 built · 4 contributed
Solo product · Deployed on the web
Money that has to reconcile to the cent, offline, from one codebase
A single dropped group member silently breaks the zero-sum invariant — and then shows everyone confidently wrong amounts.
5 built · 1 contributed
Solo product · Personal finance
Modelling the machinery a bank actually runs, not the spending you already did
A loan advertised at “6% flat” really costs about 11.3% a year. The app solves for that and says so.
All 6 layers, built
Not a list of everything I have touched. These are the five things I am actually relied on for, with the depth marked.
The user-facing half of an AI system is where most of its credibility is won or lost. I build the parts that make a model usable: streaming responses that stay readable while they arrive, conversation history that survives a refresh, generated files that download correctly, and failure states that say what went wrong.
RAG · OpenAI API · Document and data assistants
I am a frontend engineer by depth and a full-stack engineer by scope. When a feature needs a route, a query, a schema change and a background job to work properly, I would rather build all four than file four tickets.
.NET Core · REST · GraphQL · Prisma · Zod
Enterprise features are gated before they are useful. I have implemented Microsoft Entra ID and MSAL across a React frontend and the Python services behind it — acquiring tokens, passing them through to protected APIs, and handling the expiry cases that only appear once real people leave tabs open.
Protected API access · Role-aware interfaces
Files and conversations have to live somewhere, and where they live changes what the interface can promise. I work with Azure storage and databases directly — uploads and downloads, signed URLs with a sensible lifetime, and the storage configuration that makes a deployment behave the same way twice.
Cosmos DB · PostgreSQL · Prisma · SAS URL generation
Shipping means owning the result past the pull request. I have changed CI triggers, Kubernetes ConfigMaps and Dockerfiles to make a release behave, integrated branches across parallel feature streams, and spent the evening after a deployment finding out which layer actually broke.
Docker · Kubernetes ConfigMaps · Environment configuration · Release integration
The same four habits show up in every project above, and they are the reason the work crosses layers rather than stopping at the first boundary.
Requirements
The expensive misunderstandings happen before any code exists. I would rather ask the awkward question early — what happens when this document is 400 pages, what does this user see when they lack the role — than discover the answer in a production incident. Raising a risk early is cheaper than being right about it later.
Interface
A demo shows the happy path. Real use is mostly everything else: empty, loading, partial, expired, too large, offline. I build those states first because they determine the component structure, and a feature that has not been designed for failure is not finished.
Integration
Most difficult bugs live between two systems that each look correct alone. Being able to read the React component, the request, the Python handler and the storage policy in one sitting is not heroics — it is what stops a defect turning into three weeks of handoffs between teams.
Delivery
Configuration, pipelines and environments decide whether work reaches anyone. I keep them in scope: fixing the trigger, correcting the ConfigMap, reconciling branches from parallel streams, and staying with a release until it is genuinely stable.
Turning a business requirement into something buildable, and saying early when it will not work.
The React and TypeScript application people actually touch — architecture, state, states of failure.
Streaming, authentication, file transfer and the contracts between the client and everything behind it.
Backend logic in Python and Node — conversation handling, chunking, error paths.
Persistence and cloud storage: schemas, blobs, access policies, signed URLs.
Pipelines, container and cluster configuration, releases, and diagnosing production when it breaks.
I studied mechanical engineering and spent four years learning to model things that fail — where load concentrates, which assumption breaks first, and why the answer is usually at an interface between two parts rather than inside either one. Then I moved into software, which turned out to reward exactly the same instinct.
That is why I do not stay inside one layer. When a document preview renders blank for one group of users, the cause might be the component, the token on the request, the chunking in a Python service, or a storage policy in Azure — and finding it means being willing to read all four. Most of what I have shipped at PwC has involved crossing at least one of those boundaries.
The two products I built on my own exist for the same reason. One I defined myself; the other I built to a written product spec that fixed what it was and how the maths had to work. In both cases I held every engineering decision, from what the data model should be through to what happens on a bad network — and found out what I actually believed about building software when nobody else was making the call.
I work in Arabic and English, and I am based in Amman.
Associate Software Developer
PwC Middle East · Jul 2023 — Present
Intern Software Developer
PwC Middle East · Jan 2023 — Jul 2023
Junior Software Developer
PenguinIn · Oct 2022 — Jan 2023
ICT Upskilling Program (ASP.NET C#)
Al Hussein Technical University · Jun 2022 — Sep 2022
B.Sc. Mechanical Engineering
Balqa Applied University · Sep 2017 — Feb 2022
If you are hiring for enterprise AI delivery, full-stack product engineering, or a role where owning a problem end to end matters more than staying inside one layer, I would like to hear about it.
Based in Amman, Jordan. Works in Arabic and English.