Companies bring in IT consulting in two situations: when the stack has grown to the point where nobody can say what the company is actually paying for, and when a major purchase has to be decided without pressure from the vendor. My IT consulting is independent and vendor-neutral: I take no commission from any supplier. Behind it are fifteen years and more than a thousand projects in various roles, from tools of my own to multi-year programmes, including in Russia, the United Kingdom, Japan, Turkey, the UAE and Bahrain.
- What people arrive with
- IT consulting starts with a strategic audit
- Technology and vendor selection
- Digital transformation
- Rollout and team resistance
- Stack
- What I do not do
- How the time is counted
- Related services
- Frequently Asked Questions
- What happens on the first call?
- Can the audit be done without access to the configuration?
- Can you run a programme rather than only advise?
- Can you be brought in when the contractor is already chosen?
- Ready to Get Started?
What people arrive with
Three requests come up more than the rest. First: the cloud bill has grown for three quarters running and nobody inside the company can explain why. Second: a vendor has sent a proposal for a sum that cannot be checked in-house, and the decision is due in two weeks. Third: after a merger the company runs two sets of systems, and the choice of which one to keep has been postponed for a third month.
All three need the same person: someone who reads configurations and invoices rather than slide decks, and who is not selling anything.
IT consulting starts with a strategic audit
The audit answers what the company is paying for and how much of it actually works. I look at infrastructure, application architecture, how data is handled, and how technical decisions get made, who makes them and on what grounds.
An internal review almost never surfaces the awkward findings: it is hard to write in a report that the platform you chose yourself three years ago turned out to be a dead end. From outside it is visible immediately. The findings here are of their own kind: a line in the vendor proposal that nobody inside can verify; an architecture decision taken verbally and never revisited; a branch of systems left over from an acquired company.
- Infrastructure and architecture reviewed with access to the configuration, not from a description.
- Invoices broken down: what is billed, who uses it, what can be switched off today.
- Process maturity assessed: how decisions are made and what happens when something fails.
- The output is a decision table: what to switch off now, what moves to the next budget, what stays deliberately and why.
Technology and vendor selection
Picking the wrong platform costs more than any other mistake in IT, because it lives for years and drags integrations behind it. And comparing proposals from slide decks is pointless: none of them has a section on what the product cannot do.
The work starts from requirements rather than a catalogue: first I state what the outcome has to be, then I look at the market. The shortlist is tested on your scenario and your data, not on the vendor’s demo. The exit price is counted too: what it will cost to leave the platform three years in. That is usually what reorders the list: the cheapest proposal at the door holds you tightest.
For the MENA market there is one more criterion that rarely reaches comparison tables: the quality of local implementation. The same product is supported very differently in Dubai and in London, and that usually surfaces after signing.
Digital transformation
The word is normally used to sell replacing one set of systems with another. The practical part lies elsewhere: after a merger you have two sets of systems, both live, and before any purchase someone has to decide which set stays and which one runs out its contract. Until that decision is made, every new integration gets written twice.
The programme is cut into quarterly stages, and each carries its own number: how many systems retired, how many integrations removed, what the monthly bill became. If the number has not moved, the next stage does not start.
Rollout and team resistance
Rollouts fail not because of the software but because nobody explained to people what changes in their work tomorrow. Resistance is almost always rational: someone is defending a process they are accountable for against a change they do not understand.
There is no universal recipe here: what works in a London fintech does not work in a family business in Dubai, and a Turkish manufacturer resembles neither. That difference goes into the plan from day one rather than being added at the training stage.
Stack
Below is what I use when taking somebody else’s stack apart. The effect of the changes I read on your own dashboards: usually Grafana or Metabase.
| Layer | Tools |
|---|---|
| Process maturity | COBIT, ITIL |
| Infrastructure inventory | Proxmox VE, Docker |
| Declared versus running | Terraform, Ansible |
| Architecture diagrams | C4 model |
What I do not do
- I do not resell licences or hardware, and I hold no vendor partner status.
- I do not sign off a decision that has already been made in order to lend it outside weight.
- I do not recommend anything you cannot check yourself: behind a recommendation stands an invoice, a config file or an export of yours, not my authority.
- I do not replace your in-house team: after an audit the answer is often one sysadmin on the payroll, and the report puts that in plain words.
How the time is counted
Consulting is billed hourly, which is fairer than a fixed sum when the scope is not known in advance. The rate is $500 per hour (AED 1,835). An audit of a mid-sized stack takes 30–60 hours, supporting a vendor selection 20–40, and taking part in a transformation programme is counted monthly.
The first conversation is free and exists precisely to establish whether there is work here for an outside consultant. Sometimes the answer is no, and that is a normal outcome.
Related services
If the question is about defending the perimeter, devices and monitoring, that is a separate service: information security. If you need continuous technical leadership rather than a one-off review, see fractional CTO. When the audit has to become a three-year plan with owners and deadlines, that is strategic planning; when the goal is to take manual work out of one specific process, that is business automation.
Frequently Asked Questions
What happens on the first call?
The call runs 15–30 minutes: it is there to establish what does not add up. Then comes a scope description with an estimate in hours. Sometimes what arrives instead is a one-page email: three things your own team can check.
Can the audit be done without access to the configuration?
No. Read access is needed: a review based on descriptions and screenshots produces a handsome report and little value, since the interesting part is the gap between how a system was designed and how it is actually configured.
Can you run a programme rather than only advise?
The boundary runs along accountability: in consulting I answer for the quality of the decision, while carrying it out belongs to whoever holds authority inside. If I am the one who has to answer for the outcome, that is already fractional CTO.
Can you be brought in when the contractor is already chosen?
Yes, often. I do not replace the contractor and I do not negotiate in your place: I read what they propose and translate it into deadlines, risks and money. The contested points surface before signing rather than at acceptance.
Ready to Get Started?
Send me a vendor proposal or the list of systems you pay for: on a free call I will show what is worth checking first. Send the documents for review.