ramallah, palestine
Understand the person first, then build the tool.
I grew up experiencing apps and systems built for someone else, and noticing how much gets lost in that translation. That noticing became a career: turning rigid systems into workflows that work for real people, often with non-technical teams and low-cost tools.
01 // who's behind this
I studied Computer Science and International Relations together at Birzeit University, the first to combine them there, because the people shaping digital systems need to understand the political, cultural, and human contexts those systems operate in.
I've sat with government offices, NGOs, startups, and grassroots teams. The problem is different every time. What stays the same is the order of operations: understand the person, then build the tool, not the other way around.
That usually means working with non-technical teams, tight budgets, and tools that have to hold up on patchy internet and older phones.
02 // how the work actually moves
Built with احسان, not just function
احسان doesn't translate cleanly. The closest English gets is "intention and excellence," doing something in the most complete way possible, not because you're asked to, but because the person on the other end deserves it.
Hear from the client
Sit with what they're actually asking for, not just the ticket.
Observe the problem
Go to where the work happens and watch it in context.
Create a reference document
Put what's true on paper, so everyone is solving the same problem.
Research options
Map what exists, what's affordable, and what fits the constraints on the ground.
Showcase solutions
Bring real options back to the client, with trade-offs laid out plainly.
Test it in context
Put it in front of the people who'll actually use it, not a demo audience.
Observe again
Watch what happens once it's real, and adjust for what the test surfaces.
Capacity build, if needed
Hand it off properly, so the team can run it without me.
a detail that mattered
For a fleet of truck drivers logging their hours, I built personalized login links that signed each driver in directly, no passwords, no typing on a small screen with cracked reception. Once in, he selects what he's working on today, or goes with defaults pulled from his previous routes. From there he sees a panel with his hours and the areas he worked in, which he can only edit or add to, plus a space for notes. The moment he taps that link, his supervisor sees it too, live, on the other end.
None of that came from a design system. It came from sitting with drivers on the ground, and the kind of trust that only comes from human connection.
03 // where this has shown up