العربيةStart a project
Start a projectMessage us on WhatsAppالعربية

How we work

Engineering before code.

Most projects don’t fail in the code. They fail before it: requirements not understood, architecture not thought through, decisions taken too late. So every project of ours goes through eight stages, each ending with something you receive, and a decision that is yours before we move on.

  1. Stage 1 / 8

    Discovery

    Because the costliest mistake in any project is building the wrong thing well.

    What we do

    • We sit with whoever decides and with whoever will actually use the system — never only one of them.
    • We see the work as it runs today: where time goes, where mistakes repeat, where money leaks.
    • We set out the constraints from the start: budget, dates, existing systems, regulatory requirements.

    What you receive

    • A written summary of the problem as we understood it, in your words, not ours.
    • The risks we can see early, and what we propose for each.

    Your decisionHave we understood the right problem? We don’t move on until you say yes.

    What we ask (3)
    • What happens today that you don’t want happening in six months?
    • Who will use the system every day, and what frustrates them about the current way?
    • After launch, how will you know the project succeeded?

  2. Stage 2 / 8

    Product definition

    Because “everything matters” means nothing ships on time.

    What we do

    • We turn discovery into user journeys: who does what, in what order, and why.
    • We rank the features: what the product cannot work without, and what comes next.
    • We write acceptance criteria for each feature: when it is genuinely done.

    What you receive

    • A written scope for the first release, with what was left out and why.
    • Acceptance criteria you can test every feature against yourself.

    Your decisionWhat goes into the first release, and what waits.

    What we ask (2)
    • If the product launched tomorrow with only three features, which three?
    • What must never happen in this system?

  3. Stage 3 / 8

    Architecture

    Because what is decided here is what costs the most to change later.

    What we do

    • We design the data, the APIs, the infrastructure it runs on, and how it connects to what you have.
    • We build security into the design: who sees what, where data lives, how it is protected.
    • We choose technology by what the product needs, not by fashion: the expected load, who maintains it, the cost.

    What you receive

    • A short architecture document: the components, the data, the integrations, and the reason for each choice.
    • A written security plan for data and permissions.

    Your decisionThe choices that shape your long-term cost: hosting, integrations, and how far it must scale.

    What we ask (3)
    • How many users do you expect in a year, and in three?
    • Which data in this system is sensitive, and who must never see it?
    • Which systems must it talk to?

  4. Stage 4 / 8

    Interface design

    Because a system that needs explaining won’t be used the way it should.

    What we do

    • We start with structure before colour: what the user sees first, where they press, what happens next.
    • We design mobile-first when the user is on a phone, and in Arabic and English from the start, not translated later.
    • We build one design system, so every new screen belongs to the same product.

    What you receive

    • Interactive prototypes you try on your own device before a line of code is written.
    • A design system: colours, type, components and their states.

    Your decisionIs this what your team and customers will use? Change is cheap here and costly after building.

    What we ask (2)
    • Who is your least technical user, and how do we make the system clear to them?
    • On what device, and in what moment, is it used: at a desk, between patients, on the move?

  5. Stage 5 / 8

    Build

    Because you should watch the product grow, not wait months to see it all at once.

    What we do

    • We build in short stages, each ending in something working that you see and try.
    • Every line is code-reviewed before it is merged, and automated tests run on every change.
    • Version control and automated deployment, so running the product never depends on one person or one machine.

    What you receive

    • A working version at the end of every stage, on a test environment of your own.
    • A report of what was done, what slipped, and why.

    Your decisionPriorities between stages, when what you see reveals something the paper didn’t.

    What we ask (1)
    • Having tried this stage: what wasn’t what you pictured?

  6. Stage 6 / 8

    Quality assurance

    Because the first user shouldn’t be the one who finds the bugs.

    What we do

    • We test what must work and what must be refused: permissions, bad data, deliberate attempts.
    • We try it on real devices, browsers and screen sizes, in Arabic and English.
    • We measure performance under load, and review security before any launch.

    What you receive

    • A test report: what was tested, on what, what was found and how it was fixed.
    • A launch checklist that tells you the product is genuinely ready.

    Your decisionThe launch date, once you have read the test report.

    What we ask (1)
    • Which failure on launch day would hurt you most?

  7. Stage 7 / 8

    Launch

    Because launch is a planned working day, not a moment of nerves.

    What we do

    • We prepare production, the domain, certificates, backups and monitoring before launch day.
    • We migrate data from the old system if there is one, and verify it.
    • We train your team, and stay close in the first days.

    What you receive

    • A system running on infrastructure you own, under your accounts and permissions.
    • The source code and designs, and operating documentation.

    Your decisionWho on your team holds administrative access, and who receives the alerts.

    What we ask (1)
    • Who will own the system on your side after launch?

  8. Stage 8 / 8

    After launch

    Because a product starts its life at launch, it doesn’t end it.

    What we do

    • A 30-day warranty after delivery, in which we fix defects at no charge.
    • Then an optional maintenance contract: monitoring, security updates, fixes and continued development.
    • We follow how the system is actually used, and propose what is worth improving.

    What you receive

    • A product that stays secure and current, and a team that knows it from the first line.

    Your decisionWhat the relationship becomes after the warranty: maintenance, continued development, or a full handover to your team.

    What we ask (1)
    • What did the first month of use teach you, and what is the product’s next step?

What governs every stage

Five principles we don’t bend.

  • 01

    No surprises

    You know what is being built, when, at what cost, and what slipped and why. A problem raised early is always cheaper.

  • 02

    Security from day one

    Security enters the architecture in the third stage; it isn’t added after launch.

  • 03

    What is built is tested

    Code review and automated tests on every change, not just at the end of the project.

  • 04

    Your ownership, in full

    The source code and designs are yours once paid, on infrastructure you own, and running it doesn’t depend on us.

  • 05

    Delivery discipline

    Agreed stages and dates are part of our engineering process, and followed every week.

The rhythm

How you stay informed, without chasing us.

  1. Every weekA short report: what was done, what is next, and what needs your decision.
  2. End of every stageA demo of a working version you try yourself, then your decision before we move on.
  3. Any timeA direct channel to the team, with a reply within a working day.

Questions

About the way we work.

Does every project go through all eight stages?

Yes, at its own size. On a small project discovery may be one session and the architecture one page. What matters is that no stage is skipped, not that it is long.

What if the requirements change during the build?

They always do, and the short stages exist for that. We weigh a change’s effect on scope, date and cost, and put it to you before starting it. The decision is yours.

I have an existing system. Do we start from scratch?

Not necessarily. We start by understanding what works well in it and what holds you back, then decide with you: extend it, connect it to what we build, or replace it in stages.

Can I work with you from outside Egypt?

Yes. We work with clients in Saudi Arabia, the Gulf and worldwide, remotely, in clear stages with regular meetings, in Arabic and English.

Let’s start with stage one.

Tell us what you want to build, and we’ll begin by understanding it. We’ll get back to you within 24 hours.

Start a projectMessage us on WhatsApp