Software engineerAmman, Jordan
I’m Zaid Haddadin. At PwC Middle East I build enterprise web applications for large organisations in the region, from requirements through to delivery. One of those projects was an AI assistant interface: responses that stream in as they are generated, conversation history that survives a refresh, and previews of the documents and spreadsheets it produces. I work on what sits underneath as well - authentication across React and Python, Azure storage, and the deployment configuration nobody notices until it breaks. I have also built and shipped two products on my own.
Where I work
Six layers between a requirement and a user. 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.
These are products I built by myself, which is why what I own at each layer can be stated exactly rather than implied. Client work is listed under experience rather than dressed up as a case study.
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.
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.
Separate engagements, listed separately. Each item is one piece of work rather than a programme assembled after the fact.
PwC Middle EastJul 2023 - PresentAmman, Jordan
PwC Middle EastJan 2023 - Jul 2023Amman, Jordan
PenguinInOct 2022 - Jan 2023Amman, Jordan
Not a list of everything I have touched. These are the 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. My work is what happens while an answer is still arriving, when it arrives only partly, and when it does not arrive at all - and what the screen says in each case. The interface and the service boundary behind it are mine; the model and the quality of what it retrieves are not.
RAG · OpenAI API · Document and data assistants
I am a frontend engineer by depth and a software engineer who works across the stack. 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, and the gate is where the production-only problems live: whether a token is still valid by the time the request is finally made, whether an expiry fails in a way the user can act on, and the difference between a route that is merely hidden and one that is genuinely protected.
Protected API access · Role-aware interfaces
Where a file or a record lives changes what the interface is allowed to promise. The judgement is in the join: how long a signed URL should live and what it should be permitted to do, what belongs in a database rather than in object storage, and which settings have to match across environments before a deployment behaves the same way twice.
Cosmos DB · PostgreSQL · Prisma · SAS URL generation
Shipping means owning the result past the pull request, and the specifics are unglamorous: which setting differs between staging and production, what a pipeline does on a re-run rather than a first run, and how to tell a broken deployment from a broken build.
Environment configuration · Release integration
The same habits show up in everything 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 deployment configuration, 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, and what it does when something fails.
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, environment and deployment 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 has involved crossing at least one of those boundaries.
The two products I built on my own exist for the same reason. Both started as my own idea, and in both I held every decision from the product definition through to what happens on a bad network - which is how I 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.
ICT Upskilling Program (ASP.NET C#)
Al Hussein Technical University · Jun 2022 - Sep 2022
340 hours of technical and professional training.
B.Sc. Mechanical Engineering
Balqa Applied University · Sep 2017 - Feb 2022
Simulation work in ANSYS; contributed to papers with supervising faculty.
I am glad to talk about any of this - how one of these was built, a decision you would have made differently, or a problem that crosses more layers than it comfortably should.
Based in Amman, Jordan. Works in Arabic and English.