Duloq
Start a project
How we work

Four phases. No surprises.

This is the whole method, written down. Discovery is chargeable and deliberately small so both sides can find out whether the project is worth doing before anyone commits a year to it. Roughly one engagement in six ends there, with our recommendation not to proceed.

1

Discover

2 weeks

Two weeks with your people. We leave with a scored backlog, a data readiness report and a fixed-price proposal.

Discovery is chargeable and deliberately small. It exists so that both sides can find out whether the project is worth doing before anyone commits a year to it. Roughly one engagement in six ends here, with our recommendation not to proceed — which is the outcome the fee buys.

What happens

  • Workshops with the people who do the work, not only those who sponsor it
  • Data readiness assessment against the actual tables, not the documentation
  • Technical review of the systems we would have to integrate with
  • Value and feasibility scoring for each candidate use case

What you receive

  • Scored and sequenced backlog
  • Data readiness report
  • Target architecture sketch
  • Fixed-price proposal for the next phase
2

Prove

4–6 weeks

A working slice against real data, measured against the accuracy and latency targets we agreed.

The proof runs against your real data in your environment, never a curated sample. We agree the pass mark before we start, in writing, and we report the number whether or not it flatters us. A proof that fails honestly in week five is far cheaper than one that succeeds dishonestly and fails in month nine.

What happens

  • Build the thinnest slice that exercises the real risk
  • Stand up the evaluation harness before the feature
  • Test with the people who will actually use it
  • Cost model the production shape at expected volume

What you receive

  • Working slice on real data
  • Measured results against the agreed pass mark
  • Production cost estimate
  • Go / no-go recommendation
3

Build

3–9 months

Two-week sprints, a demo you can click at the end of each, and code in your repository the whole way.

Every sprint ends with something you can use, not a status deck. Code lands in your repository from the first commit, CI runs on your account, and the demo is the working system rather than a recording of it. If a sprint produces nothing clickable, we say so plainly and explain why.

What happens

  • Two-week sprints with a demo and a written increment note
  • Continuous integration with regression gates on the evaluation set
  • Security review before each release to production
  • Progressive rollout behind flags, with a documented rollback

What you receive

  • Production system under your control
  • Test suite and CI pipeline
  • Infrastructure as code
  • Architecture and operations documentation
4

Operate

Ongoing

We run it, or we train your team to run it — and we write down how, in Arabic and English.

Both endings are legitimate and we price them the same way. What we will not do is leave a system running that only we understand. The exit plan is written in the first month of any support contract and kept current, because a supplier you cannot leave has no incentive to stay good.

What happens

  • Monitoring, on-call and incident response against an agreed SLA
  • Model retraining and drift review on a fixed cadence
  • Quarterly cost and security review
  • Shadowing and handover sessions for your engineers

What you receive

  • Monthly service report
  • Current runbooks in both languages
  • Trained internal operators
  • A live exit plan
Principles

The rules we do not bend

These are not values on a wall. Each one costs us something in practice, which is how you can tell we mean them.

Measure before you claim

Every quality statement we make about a system has a number behind it and a test that produces that number. If we cannot measure it, we describe it as an opinion.

Ship the boring parts first

Authentication, logging, backups and deployment come before the impressive demo. They are what determines whether the impressive part is still running next year.

Write it down

A decision that lives only in someone’s memory is a decision the next engineer will reverse by accident. Architecture choices are recorded with the trade-off that produced them.

Design for the handover

We assume from day one that someone else will maintain this. That assumption changes how the code is organised, and it is the single biggest favour we can do a client.

Arabic is not a translation layer

Right-to-left layout, Arabic typography and dialect handling are design inputs from the first wireframe. Retrofitting them costs three times as much and still shows.

Say no to the wrong project

We would rather lose a contract at discovery than deliver something that should not have been built. It is cheaper for everyone, including us.

Talk to an engineer

Tell us what you are trying to build.

Send a short note and one of our engineers — not a salesperson — will reply within one business day.

Book a discovery call[email protected]