How We Work
A software project goes wrong long before anyone writes code — usually in the gap between what was described and what was understood. The way we work is built around closing that gap early, and around being straightforward about what we need from you in order to do it.
The stages of an engagement
Understand
We start with how your business runs today, including the parts that are held together informally. We ask what happens when something goes wrong, because exceptions reveal more about a process than the happy path does. Nothing is proposed at this stage.
From you: Time with the people who actually do the work, and a willingness to describe the workarounds rather than the official procedure.
Scope
We write down what the work covers and, just as importantly, what it does not. Scope disagreements are the most common way a project sours, and almost all of them are traceable to something that was assumed rather than stated.
From you: A decision-maker who can confirm priorities, and an honest answer about which problems actually matter most.
Design
We work out how the system should behave before building it — the structure of the information, how people will move through it, and where it needs to fit alongside what you already run. It is far cheaper to change a design than a built system.
From you: Review and disagreement. A design nobody pushed back on usually means nobody read it closely.
Build and integrate
We build in increments you can see, rather than disappearing and returning with a finished system. Where the work involves connecting to systems you already run, integration is treated as part of the build rather than as something handled at the end.
From you: Access to the relevant systems and someone we can ask when a question comes up mid-build.
Validate
The system is checked against the real cases your business runs — including the awkward ones. Testing against the straightforward path proves very little; the value is in confirming behaviour where your process is unusual.
From you: Real examples and real edge cases, and people from the team who will use the system doing some of the checking.
Deploy and support
We plan the move to live as a change your business has to absorb, not just a technical event — including who needs to know what, and what happens in the first weeks. After that, the system continues to need attention as your processes change.
From you: A view on timing that fits your operational calendar, and a named person who owns the system on your side.
What holds across all of it
These are not stages. They are the things we try to keep true at every stage.
Say what we do not know
An early estimate given with false confidence is worse than an honest range. If something is uncertain, we would rather say so and narrow it deliberately.
Design for the people using it
A system that is technically correct and awkward to use will be worked around, and a worked-around system produces worse data than the spreadsheet it replaced.
Arabic and English from the start
Both languages treated as first-class throughout, rather than one being added once the design is fixed — which is when bilingual support becomes expensive and shallow.
Leave you able to leave
Your data is yours, your process is documented, and nothing is structured to make moving away artificially difficult. We would rather be kept than be hard to escape.
Start with a conversation
The first stage costs you a conversation and some honesty about how things currently work. If it becomes clear we are not the right fit, that is a useful outcome too, and we will say so.