First contact and the brief
You start with a short call or a written brief: your goals, your users and the constraints you already know about, such as a deadline or a system you must connect to. You do not need a finished specification. We reply with questions and a proposed plan, usually within one business day. We work remotely and plan calls around your working day.
Discovery and scoping
Before we estimate anything, we need to understand the product well enough to be honest about it. We ask:
- Who uses the product, and what must each kind of user be able to do?
- Which systems, payment providers or data sources must it connect to?
- Which languages, devices and platforms must it support?
- What data does it hold, and who must never see it?
- What is the deadline, and what is driving it?
You then receive a plan covering design, build, security and timeline, written so that people outside engineering can read it. The estimate states its assumptions (see how we price). If too much is still unknown, we suggest a discovery sprint first: about two weeks of research, a clickable prototype, a technical approach, a threat model of the core flows and a written roadmap.
Design and prototype in English and Arabic
We design the product as a clickable prototype before anyone builds it, so you can test the main flows with real users and change your mind while changing it is cheap. English and Arabic, left-to-right and right-to-left, are designed together from the first screen, not translated at the end. Arabic and RTL design explains how, and our guide to bilingual products covers the trade-offs.
Building in short cycles
We build in short cycles and show working software every week. A weekly demo is a real, running version, not slides. You react to it, we adjust the plan, and the next cycle starts from what you said. Priorities live in a roadmap you can read, so you always know what is being built now, what comes next and what has moved.
Quality checks run as the product grows: automated tests, and a release pipeline (CI/CD) that builds and checks every version in the same way.
Security at the start and before launch
Every project begins with a threat review, also called threat modelling: we map what the product protects, who might attack it and how, and design the defences in before the first line of code. Before launch we run a security review of the finished product, and you receive a prioritised fix list. Our security practices page describes both in detail.
Testing before every release
Nothing is released untested. Each release is checked by automated tests and by people trying the real flows, on the devices and in the languages your users will use. We tell you what was tested, what was not, and any known issue before you approve the release.
Launch
Before launch we agree what ready means: which items on the fix list must be closed, which tests must pass, who approves the release, and what we do if something goes wrong in the first days. Launch is then a planned step, not a surprise. If the product serves several audiences or markets, it can be released in stages.
Handover and support after launch
At handover you receive what was built and the information needed to run it: the code, notes on how the parts fit together and how to release a new version, and a walkthrough with your team. The exact deliverables are agreed in writing.
After launch, support can take several forms: a fixed period of post-launch care, a dedicated team that keeps building month by month, or help when you ask for it. Which one fits depends on your product, and the length and terms are agreed per project.
How we communicate
- Weekly demos of working software.
- Plain-language plans: roadmaps and estimates your whole team can read.
- Estimates with their assumptions, so you can see what would change a number.
- Early warnings: if something threatens the plan, you hear it from us as soon as we see it.
- A named delivery lead on product builds and dedicated teams.
What we need from you
- One decision maker who can say yes or no, so questions do not wait in a queue.
- Access to accounts, existing systems, brand assets and content when we ask for them.
- Feedback within the week, ideally on the demo itself.
- A clear view of what matters most, so trade-offs follow your priorities.
If something is late on your side, the timeline moves, and we will say so plainly.
When the scope changes
Scope changes are normal: you learn from users, or the market moves. We handle them in the open.
- You describe the change, or we raise one we found.
- We explain what it touches (design, build, security, timeline and cost) and re-estimate.
- You decide with us: add it, swap it for something already planned, or leave it for later.
- We update the roadmap and the estimate, so everyone works from the same plan.
Payment terms, the support period, response times and contract clauses are not set on this page. They are agreed in writing for each project.