I lead frontend architecture for TAMM, Saudi Arabia's national government services platform.
Multiple product teams build on the component library and standards I own. I also write the Spring Boot services behind those journeys, the pipelines that ship them, and the LLM features on top — then own what happens in production. On the side I designed, built and still run a production platform by myself. Ten years across government, oilfield and healthcare systems.
I own systems end to end, and answer for them.
I've spent ten years on systems where mistakes are expensive: government services, oilfield operations, healthcare records, and money movement. Most of that work has been the unglamorous kind — a component library that other teams have to live with, a WebSocket stream that has to survive a drilling site's connectivity, a ledger that can't be edited after the fact.
What I'm actually good at is owning a system end to end and being the person who answers for it: the domain model, the API surface, the pipeline, and what happens when it breaks at an inconvenient hour. I'm looking for a role where I do that for a product rather than a ticket queue — architecture ownership with hands still on the code.
Requirements to production, without a handoff.
Most of my work has been in places where the person who scopes it, designs it, builds it and gets called when it breaks is the same person. These are the five stages I actually own — not a process diagram, just where my hands have been.
Scoping directly with the people who use the thing — government service owners at Elm, drilling domain experts at LMKR, clinic and operations staff on site at RISETech. I'd rather argue about scope early than discover it in UAT.
Domain model, service boundaries, API contracts and the access model, decided before the framework. On SponsorOne that meant a BRD and architecture diagrams before a line of code was written.
Angular and TypeScript at the front, Java/Spring Boot and Node.js behind it, PostgreSQL underneath — plus the shared component library and standards when more than one team is shipping into the same product.
Docker, AWS ECS/Fargate, Kubernetes and OpenShift, with pipelines on GitHub Actions and GitLab CI. Rebuilding CI/CD across TAMM's product teams cut deployment time by roughly 30%.
Datadog and CloudWatch, structured logging, incident investigation through to root cause, versioned releases with a rollback path. The stage where you find out whether the earlier decisions were any good.
TAMM — national government services platform
2021 — PresentTAMM is how citizens in Saudi Arabia access government services online — a large catalogue of services with multiple product teams shipping into it, some in Angular, some in React.
I own the shared component library, the design system, and the frontend engineering standards those teams build on, structured as an Nx monorepo with micro-frontend boundaries so teams can ship independently. The technically interesting part isn't the components — it's that my decisions are expensive to reverse. A breaking change in the library is a breaking change in every product that depends on it, all at once, so the work is mostly versioning discipline, deprecation paths, and getting agreement from teams that each had their own way of doing things before I showed up.
Alongside that I build the backend services that connect government systems to the citizen-facing apps (Spring Boot, NestJS, PostgreSQL, MongoDB), and designed the platform's authentication and access model: JWT/OAuth2, RBAC, and API key management for third-party integrations.
Not the code — the agreement. Every team already had a working way of building things before a shared standard existed, so each adoption was a negotiation, not a rollout. The lesson I took from it is that a deprecation path is a social contract as much as a technical one: if teams can't migrate on their own schedule, they route around the library instead, and you end up maintaining the thing nobody uses.
SponsorOne — sponsorship and donation platform for education NGOs
2024 — PresentSmall education NGOs track child sponsorships in spreadsheets and WhatsApp threads and reconcile donations by hand. The failure mode isn't inefficiency — it's that when a board member or a donor asks where a specific payment went, nobody can answer with confidence.
SponsorOne records every payment against an append-only ledger. Sponsors see their own money trail. Admins get reconciliation and a system-wide audit log. Zakat is tracked separately from general donations, because the accounting rules differ and combining them is a genuine problem for the organizations I built this for.
I did all of it: requirements with the stakeholders, domain model, schema, API, Angular frontend, deployment, and support.
- The ledger is append-only in the domain model and enforced again in PostgreSQL. One layer can be bypassed by a future developer in a hurry; two is harder to bypass by accident.
- Access is claims-scoped rather than filtered per request, so swapping an ID in a URL returns nothing instead of someone else's data.
I built and ran it on AWS ECS/Fargate first, then moved it to Heroku when the monthly bill stopped making sense for a platform funded by an NGO. I'd make the same call again — but I'd run the cost numbers before picking the more interesting infrastructure, not after.
LLM features, built like everything else.
The interesting part of building with models isn't the prompt. It's everything around it — streaming, failure handling, cost, and what your system does when the model returns something unusable.
OpenAI and Claude APIs behind Python services, streaming responses so the interface shows progress instead of a spinner, and defined behaviour when a call is slow, truncated, or fails outright.
Prompts designed and orchestrated as part of a real feature — versioned and reviewed like code, not pasted into a notebook and forgotten.
Python services and pipelines that handle the unglamorous parts: input shaping, retries, structured output contracts, and logs you can actually debug from at 2am.
I use AI tooling inside my own build and review loop, under the same rule I apply to any generated code: it doesn't merge until I can explain why it's correct.
RAG, embeddings, vector search, agentic workflows and LLM evaluation — I've built with all of them and I wouldn't yet claim them at production scale. I'd rather say that here than discover it with you in week three.
A decade of increasing ownership.
Elm Company
- Lead frontend architecture for TAMM, a national-scale government platform — owning the shared component library, design system, Nx monorepo structure and the engineering standards every Angular and React product team builds on. Full story above.
- Build and maintain the backend services (Java Spring Boot, Node.js/NestJS, PostgreSQL, MongoDB) that connect government systems to citizen-facing applications.
- Designed platform-wide security: JWT/OAuth2 authentication, role-based access control, and API key management for third-party integrations — plus WebSocket infrastructure for real-time notifications.
- Rebuilt CI/CD across product teams on GitHub Actions and GitLab CI, cutting deployment time by ~30%.
- Operate production workloads on AWS, Kubernetes, and OpenShift with Datadog observability that catches problems before users do.
- Set the frontend testing standard across teams — Jest and Karma unit coverage, Cypress and Playwright end-to-end — and carry releases through UAT, deployment verification and post-release monitoring.
- Mentor engineers, lead code reviews, and document architecture decisions so quality scales with the team — and the architecture outlives any one person.
LMKR
- Built mission-critical software for Halliburton's Digital Well Program — well planning and daily operations tools drilling engineers depend on.
- Worked across Java/Spring Boot services and a Node.js codebase, designing versioned REST and GraphQL APIs so evolving the system never broke existing clients — an early lesson in designing for change.
- Engineered real-time well monitoring over WebSocket streams with retry and exponential backoff, built for unstable field networks where naive implementations fail.
- Consolidated scattered backend calls into a single aggregation layer, cutting API response times ~15%; refactored a legacy Node.js codebase into independently deployable services.
- Built Angular/TypeScript frontend modules over large engineering datasets, with reusable components, validation and usability as the focus.
RISETech
- Built and extended the frontend of an OpenMRS-based electronic medical record system — patient registration, clinical encounter forms, observation capture and reporting — against the OpenMRS REST API and its clinical data model.
- Built the integration between OpenMRS and Odoo so clinical activity flowed through to billing, inventory and procurement, mapping patients, services and stock items across two different domain models.
- Built enterprise Angular and React applications for healthcare and IoT clients — domains where correctness and security are non-negotiable.
- Implemented authentication and role-based access control end to end: JWT, route guards, session management, secure API access.
- Deployed and configured the product in client environments, and ran onboarding, data migration and go-live support alongside clinic and operations staff.
Independent — SponsorOne
- Designed, built, deployed, and now run a sponsorship and donation platform for education NGOs end to end — see the SponsorOne case study above.
How I build — the part that doesn't show up in a stack list.
Boundaries first
Domain logic stays free of the framework. It's a discipline that costs you speed early and pays back the first time you replace a database, a queue, or a cloud. I've had to do all three.
Enforce critical rules twice
An append-only ledger lives in the domain model and again as a database constraint. A future developer under deadline pressure will find the one path you didn't guard.
An LLM is a dependency, not a feature
A model call is an unreliable network call that sometimes returns confident nonsense. It gets what any other dependency gets: a timeout, a fallback, a structured output contract, and a log of what actually came back.
Test against a real database
Integration tests run on Testcontainers, not mocks. A mocked test tells you your mocks agree with each other.
Deep where it matters.
What I'm looking for
Senior engineering or architecture roles where I own a system rather than a backlog. Riyadh-based, open to relocation. I'm currently on a transferable Iqama, so I can move without a release complication. Email is fastest — I'll get back to you quickly.