What working with me looks like.

On a football booking app, I found out too late that what I was building and what the client expected had drifted apart. I should have checked much earlier. Now I show working examples early and often, so a gap shows up while it is still cheap to fix.

That means talking directly, not through a chain of messages. I want to see the current process, a sample document or the software you use today. For a new product, I want to know who will use it and why.

I split the work into milestones and give each one a fixed price, based on my estimate of the hours at SAR 250 an hour. You pay for a milestone after it is delivered.

If an off-the-shelf tool does the job, I’ll tell you, even though it means less work for me. If a change comes up mid-project, we price it before I build it.

You see the software as it takes shape, on your own phone or computer. For an internal system, the people who will use it every day try it too, because they find the problems nobody else does.

Before handover I test the main workflows, the permissions and what happens when someone makes a mistake. Then we agree on hosting, access, documentation and any support after launch.

A staff member should be able to find a request, see where it stands and fix a mistake. A customer should be able to finish what they opened the app to do.

In Mounjari, I care about how fast it opens and how the Arabic reads. When a user says she is female, the app addresses her in the feminine. I bring that level of care to client work.

The code repository, hosting and store accounts are created in your name, and I am added as a collaborator. You can look at the work any time, and if we stop, everything is already with you.

I use coding agents, established libraries and managed services, and I review and test what they produce. If something goes wrong or the scope shifts, you hear it from me first, along with your options.