How do you scope a project?
Scoping starts with the model, not the screens. Before any interface is designed, we define what the system is actually about: the order lifecycle, the booking state machine, the sync rules between a device and a server, and the awkward states everyone would rather not think about. That gets written down and agreed, because every feature afterwards is either straightforward or impossible depending on those decisions. Once the model is settled, scope is a much smaller argument.
What's actually in a fixed-scope contract?
A defined outcome for a defined price, from idea to launch. It depends on the scoping work happening first: a price can only be fixed against an outcome described precisely enough that there is no argument later about whether it was delivered. So the order is the shape of the system and what "done" means first, price and delivery plan second. Work that genuinely cannot be defined up front fits one of the other models better, and saying so early is cheaper than discovering it halfway through.
How much does a project cost?
Consultation time has a published price: $200 for an hour, $350 for two, and the first twenty minutes are free. Projects are different, and I don't publish a rate for them, because a number without the scope attached would be misleading. The same feature list is a different project depending on how much of it integrates with systems you don't control, how much existing code has to keep running, and how much of the lifecycle you need me for. Describe those three things in an email and you get a real number. If budget decides it, say what you have and I'll tell you straight.
Which way of working together should I choose?
Five models, differing mainly in how much of the outcome I own. A freelance project is focused delivery of one product or feature. A fixed-scope contract is a defined outcome for a defined price. A technical partnership is ongoing architecture leadership as you grow. A consultation is a review, or direction on a decision that is hard to undo. Team training levels up your own engineers. If you aren't sure, describe the situation rather than the format.
How do we start?
Send an email describing what you're working on. Useful first messages cover four things: what the business does, what you're trying to change, what already exists, and any constraint already fixed. My first reply is normally questions rather than a proposal, because a proposal written before those answers is a guess. Once they're answered the work gets defined: what it is, which model fits, and what the first deliverable looks like. There is no form and no intake process.
Who does the work, and where are you based?
I do the thinking that decides how a project turns out: the business analysis, the architecture, and the decisions that are expensive to reverse. You deal with me directly rather than an account manager, and delivery is resourced to the project. I also run Makook, an e-commerce platform I founded, built, and operate today. I'm from Damascus and based in Malaysia, working remotely in Arabic and English across the Gulf, the wider MENA region, the UK and the US. Where being in the room matters, I travel.
We already have a system and engineers. Where do you fit?
Replacing a working system is the expensive option and rarely the first thing to consider, so an engagement that starts with a system you own starts by understanding it: what it does today, what the business can no longer change, and what has to keep running. That assessment is a deliverable in its own right. Alongside your engineers it takes one of three shapes: architectural ownership of a system they keep building on, a second pair of senior eyes on hard-to-undo decisions, or training them directly.
What happens after launch?
Launch is a milestone in a system's life, not the end of it, which is why ongoing work is a separate model rather than an assumption baked into every project. A technical partnership covers exactly this: continuing architecture leadership as the business grows, so the person who designed the system stays involved in how it changes. If you don't need that, the alternative is a system your own engineers can carry — and whether they can is mostly decided long before launch, by whether the modules have real boundaries.