Digital & Technical
Five technical disciplines. Systems adapted to Iraqi reality, not imported as-is. And products built here, for those working here.
A successful technical system in Iraq isn't necessarily the newest or the most expensive. It's the system that knows where it is.
It understands that power cuts happen, so it accounts for generators in its design. It understands that the accountant writes in Arabic and the manager in English, so it accommodates both. It understands that the team is distributed across three provinces, so it secures communication between them even when the internet goes down.
This page lays out how we build systems that know where they operate — and how, over years of practice, we've created our own products to solve common problems that imported solutions never quite addressed.
We don't sell off-the-shelf packages. Every project begins with a question: what do you actually need, and what is the reality it will operate in? Then we choose tools accordingly.
Global ERP systems (Oracle, SAP, Odoo, Microsoft Dynamics) are built on IFRS assumptions. That's not wrong, but it doesn't align directly with the Iraqi Unified Accounting System mandated by the General Commission of Taxes. We select the system by project, then adapt it — not the other way around.
In this domain, we deploy DocxKeeper — an electronic archiving system we've built over years, currently in use across most Iraqi government departments and a significant number of private companies. Designed from the ground up for:
In Iraq, the internet isn't always stable, especially during national exam periods when entire ISPs can go offline for hours or days. Our approach in these cases: closed Intranet networks linking organizational sites to each other without routing through the public internet.
As a representative project, we built an Intranet network for a project under the General Federation of Iraqi Workers' Unions linking sites in Basra, Babylon, and Baghdad. The project's exposure to internet outages was eliminated entirely.
Many companies in Iraq own good systems that simply don't talk to each other. The finance system operates in isolation from inventory; inventory in isolation from sales. Integration turns fragmented systems into a unified architecture — without replacing anything.
When no available market system serves a specific project's needs, we build one. Our product Daftarak is an example — a mobile and desktop application for managing project accounting in execution-heavy projects (large construction, contracting firms). Built because traditional accounting systems don't handle the complexities of Iraqi construction project flows smoothly.
Daftarak — soon opening its doors online.
Every technical project, regardless of size, follows the same fundamental rhythm. The difference is in depth, not in structure.
We understand the existing workflow — not as it should be, but as it actually is. We listen to the teams who'll use the system. We map risks, document needs, define priorities.
We select tools by project. We map integrations. We plan phased deployment. We deliver a technical report confirming mutual understanding before any execution.
Installation happens in phases, with minimal disruption to existing operations. System training begins early, not at the end. Live transition is planned, with rollback options at each stage.
We don't leave the system after delivery. Support contracts include: updates, troubleshooting, ongoing training for new team members, and feature development per evolving needs.
Some fifty-five hundred years ago, the inhabitants of Mesopotamia invented something that altered the trajectory of humanity: cuneiform writing. Not the first alphabet in the modern sense, but the first organized documentation system in history.
Before it, knowledge was oral — scattering with memory, dying with its bearers. After it, information became recorded in an agreed-upon system: stable symbols readable by anyone who learned them. Portable across space — a tablet traveling from Ur to Babylon carrying the same meaning. Portable across time — a tablet read thousands of years later, carrying the same message.
This wasn't literature. It was information infrastructure. What we do today in information systems follows the same principle: transforming scattered knowledge into a unified, transferable, enduring system.
At Tigris Gate, we build systems with the logic Sumerians used to build their tablets — designed so information remains readable years after it was recorded.
Typical numbers from our practice. Not promises — reasonable ranges for sound planning.
3-6 months from analysis kickoff to live launch. Varies by: number of users, supply chain complexity, state of existing data, and degree of customization required.
6-10 weeks, covering: scanning, indexing, quality verification, launch in the search system. Quality takes precedence over speed at every stage.
We target 99%+ uptime for critical systems (accounting, archiving, networks). This requires backup designs for power, network, and servers — all factored into initial design.
Each project gets a dedicated team including: deployment engineer, team trainer, and tier-2 support. Typical response time for outages: within 4 hours for critical system failures.
Buying Oracle ERP doesn't make the accountant work on it tomorrow. The gap between the deployed system and the used system is training and accompaniment. This gap is what causes a large portion of ERP projects worldwide to fail — not the technology. Training isn't a final phase. It starts in week one.
In Iraq specifically, power outages, server damage, even natural disasters are everyday probabilities. A system without automated daily backup is a system waiting for disaster. We design every system with three layers of backup: local, off-site, and encrypted cloud.
Most breaches aren't sophisticated technical attacks. They are simple phishing emails, weak passwords, or accounts shared between employees. Information security training is part of every system we deploy, not an optional add-on.
A system serving a 50-employee organization may not serve it at 200. A system designed for trading may not fit after expansion into manufacturing. We account for this from the start: scalable design matters more than the cheapest system.
We don't start with "what system do you want?". We start with a sharper question: "what problem are you trying to solve?". Tools come after. A first conversation to understand your need, then we draft the technical file that fits.
Let's Talk →
