Method

How we work

Most vendors describe their process in words that could apply to anyone. This page is specific enough that you can hold us to it, and short enough that you will finish it. It describes a build; staff augmentation and managed services are set out on their own pages.

The shape of an engagement

  1. One meeting, at your office, no charge. We ask to sit with the people who do the work, not only the people who manage it. Half a day is usually enough. We are looking for the process that costs the most hours, not the one that is most annoying to talk about. You should leave that meeting with our honest view of whether software helps at all.
  2. We pick one thing, and write it down. Narrow enough to finish in two weeks, real enough that finishing it changes someone’s day. You get a short written scope: what is in, what is out, what “done” means, and what happens if you change your mind. Two pages, in plain language, in Arabic and English.
  3. A fixed price and a fixed date, before you commit. Both in the proposal. If we cannot price something confidently, we say which part and why, rather than hiding a margin in it.
  4. A month of building, in the open. You get access to the working system from the first days, not a demo at the end. A short written update twice a week. If we are going to be late you hear it as soon as we know, not on the deadline.
  5. It goes live, and your people are trained. Deployed into real use. Two training sessions, recorded. Source code, documentation and accounts are already in your name. 30 days of defect fixes at no cost.
  6. You decide what happens next. Extend, move to a monthly support arrangement, or stop. Stopping is a real option and costs you nothing beyond what you have already paid.
Boulevard World, Riyadh

Six steps. You see running software in the first days of each one.

Boulevard World in Riyadh (2023) — Saudi Press Agency (SPA), CC BY-SA 4.0, via Wikimedia Commons

Quality

The six gates

Inside the build, every change passes six checks before it can reach you. Three are automatic. Three need a human signature.

  1. GATE 01SpecificationHuman
  2. GATE 02Test-first designHuman
  3. GATE 03Build, with AI agentsMachine + human
  4. GATE 04Automated checksMachine
  5. GATE 05Human code reviewNamed person
  6. GATE 06Release approvalNamed person

A filled dot is a machine gate A ring is a gate where a named human signs

1 — Specification
The change is written down and agreed before anyone builds it.
2 — Test-first design
The test that proves it works is written before the code.
3 — Build
Our engineers build it, working with AI agents.
4 — Automated checks
Tests, security scanning and code-quality checks all pass.
5 — Human code review
A senior engineer reads every line and can reject it.
6 — Release approval
A named person approves the release to your environment.

Gates 5 and 6 are signed by a person we will name in your contract. That is the answer to the question every security reviewer eventually asks about AI-assisted development, and we would rather give it to you in writing at the start than defend it later.

How we communicate

  • Written updates twice a week, short, in the format you prefer — email, WhatsApp or your own tool.
  • A call weekly, thirty minutes, only if there is something to decide.
  • Language Arabic or English, your choice, for both conversation and documents.
  • Bad news same day. A delay you hear about early is a schedule problem; one you hear about late is a trust problem.
  • Who you talk to — the engineer building it. There is no account manager in between.

How we price

  • Fixed price is the default for anything with a scope we can write down.
  • Monthly fee for support and managed services.
  • Monthly rate per person for staff augmentation only.
  • Hourly billing we avoid. It pays us for slowness, which is the wrong incentive to put between us.
  • Payment by milestone, against something working that you can see.
  • Currency SAR, on a Saudi invoice.
  • Change requests priced and dated before we do them.
King Fahd Road, Riyadh

A fixed date is a promise two people keep.

King Fahd Road Riyadh SN 2012 — haitham alfalah, CC BY-SA 3.0, via Wikimedia Commons

What we need from you

Fixed dates are a two-sided promise. These are the five things that break them, and we will raise any of them the day it happens.

  1. One person who can decide. Not a committee. Someone who can answer a question within a working day.
  2. The real calendar. Tell us at the start about Ramadan, the Eid holidays, your audit period and your busy season. We plan the dates around them. A date agreed without them is a date that slips, and neither of us gains from pretending otherwise.
  3. Access on day one. Systems, test data and the accounts we need. One month of work does not survive ten days of waiting for a password.
  4. Time from the people who do the work. A few hours in total. Their knowledge is the specification.
  5. Decisions inside the agreed window. If a decision takes a week, the date moves by a week, and we will say so in writing at the time rather than at the end.

Where your data lives

Agreed in writing before we start: which data we touch, where it is stored, who on our side can reach it, and whether anything leaves the Kingdom.

PDPL is enforced — SDAIA has issued 48 enforcement decisions and fines reach SAR 5,000,000 per violation — and the exposure is yours, not ours. Where we can work with anonymised or synthetic test data instead of real records, we will, and we will suggest it before you have to ask.

After the project

  • 30 days of defect fixes at no cost.
  • A monthly support arrangement if you want one. An option, never a condition.
  • If you take the system elsewhere, we hand over and brief the next team. One day, free. We do not hold accounts, domains or access as leverage.
Book the first meeting