Frequently shape
Asked Question
Email contact@abdullahkhaled.com with the problem you are solving, your deadline, and any constraints you already know about. I reply personally and propose a short call. On that call we cover goals, users, existing systems and budget range. You then receive a written scope with deliverables, a timeline and a fixed price. Nothing is committed until you approve that document.
I do not publish hourly rates, because an hourly rate tells you nothing about what a system costs. I work in fixed-scope engagements: an agreed deliverable, an agreed timeline and an agreed price, so you carry none of the risk from my estimating. Cost depends on scope, integrations, and how much of an existing system has to be understood first. Send your requirements and you will get a quote to review.
It depends on scope, so I quote the timeline together with the scope instead of guessing on a call. Useful reference points: an architecture and codebase review runs about two weeks, and a build sprint that ships one working slice to production runs about four weeks. Larger platforms are delivered as a sequence of those sprints — at RB Agency that rhythm produced four client platforms in eight months.
You do. The source code, the database design and every artefact produced during the engagement belong to you, and full intellectual property transfers to you on final payment. The work lives in your repository from the first commit, not mine. There are no licence fees, no hosting lock-in and no hidden dependency on me — the whole point is that another engineer can pick it up.
Backend: Node.js with NestJS or Express, and PHP with Laravel. Frontend: React, Next.js and Angular on TypeScript. Data: PostgreSQL, MySQL, MongoDB, SQL Server and Redis. Infrastructure: Docker, GitHub Actions, Linux and Nginx, hosted on AWS, DigitalOcean or Hetzner. I also build real-time features with WebRTC and Socket.io, and mobile or desktop builds with Ionic, React Native and Electron.
Yes, and it is a large part of what I do. I start with a review: read the code, map the schema, run it locally, and write down what is safe to change and what is load-bearing. You get findings ranked by risk before anyone refactors anything. From there we either stabilise and extend in place, or plan a staged migration with the old system still running.
You get a working deployment you can open, not a status report you have to trust. I work in short cycles with a review point each week: what shipped, what is next, and anything that changed the estimate. Day to day I use whatever your team already uses — Slack, Teams or email — and issues live in your tracker. Decisions that affect architecture are written down, not just said on a call.
I am based in Giza, Egypt (UTC+2, and UTC+3 during summer time) and work remotely with clients worldwide. That gives a full working-day overlap with Europe, the Gulf and Africa, and a reliable morning overlap with the UK. North American mornings fall in my late afternoon and evening. Availability and response expectations are agreed in writing before an engagement starts.
Yes. I work in Arabic and English, and I build bilingual products where Arabic is a first-class locale rather than a mirrored afterthought. In practice that means proper RTL layout, correct typography and number handling, translated content models in the database, and an admin panel your Arabic-speaking team can genuinely operate. This site itself runs in both languages.
Every engagement ends with a handover, not a disappearance. You receive deployment and rollback runbooks, architecture notes explaining the decisions behind the build, and a walkthrough session with your team. After that you can keep me on a monthly arrangement for maintenance, code review and new features, or take it fully in-house. I started out teaching, with 500+ students trained, so handover is written to be understood.