Software Engineer for systems that have to run in the real world.
- Industrial Automation
- SCADA
- IoT & Telemetry
- Cloud & APIs
I design and build the software that carries a measurement from a meter, inverter or PLC all the way to an operator's screen — protocol integration, edge acquisition, ASP.NET Core services, the databases underneath them, and the servers they run on.
One engineer across the whole signal path
I am a software engineer specialising in .NET backend development, industrial IoT, SCADA and real-time data systems. My work sits where software meets physical equipment: designing high-throughput APIs, distributed data-acquisition platforms, industrial communication integrations and the monitoring interfaces engineers actually use.
That means I am comfortable at every level of the stack — reading a register map off an inverter, writing the background service that polls it, modelling the time-series table it lands in, exposing it through an authenticated REST API, and configuring the Linux or Windows server that keeps the whole thing online at a remote site.
I work alongside electrical, automation and mechanical engineers, which shapes how I build: systems have to survive unreliable links, restarting devices and sites nobody can visit at short notice. I also lead a small development team, including Flutter developers who deliver the mobile side of client projects.
Complete technical systems, not just interfaces
Each of these is work I do end to end — specification, software, integration, database, deployment.
Seven layers, one engineer
Most software roles stop at one or two of these. The value I bring is that a problem never has to be handed across a boundary — the device, the protocol, the service, the database, the screen and the server are all mine to reason about.
From field device to cloud
A real deployment is a chain, and it is only as good as its weakest link. Step through each stage to see what I build there.
Systems in production
Grouped by the engineering system they form rather than by repository. Several are internal industrial software whose interfaces cannot be published — those are shown as architecture diagrams.
Where the work happens
Bachelor of Computer Science
University of Jordan — Amman, Jordan
Tools, grouped by what they are for
Organised by the job each technology does, rather than as an undifferentiated wall of logos.
Software still has to run somewhere
Industrial deployments live on remote sites with unreliable links. Getting an application written is half the job; keeping it reachable, secure and recoverable is the other half.
Self-hosted remote access for field equipment
Industrial sites rarely allow third-party remote-desktop services onto their network. I deploy and operate self-hosted remote-access infrastructure so support traffic stays on servers we control.
- RustDesk server deployment on a Linux VPS — self-hosted rendezvous and relay services
- Firewall rules, port exposure and DNS records for the relay endpoints
- WireGuard tunnels and port forwarding for reaching devices on private site networks
- TLS termination, key handling and restricted access paths for support sessions
- Remote engineering support and commissioning without a site visit
To be clear: RustDesk is open-source software I deploy and operate — not a product I authored. What I contribute is the server, network and security architecture that makes it usable for industrial support.
Let's build something that has to work in the real world
Whether it is an industrial system, a backend platform, or getting equipment talking to software that does not exist yet — tell me what the system has to do and I will tell you how I would build it.