The Concept
The holding model is not a legal structure. It's a philosophy about how software should be built, owned, and operated in markets that deserve better products than they currently have.
The Thesis
Most software in the Saudi market is built by agencies, freelancers, or consultant-led projects. The incentive of everyone in that model is to deliver the scope and collect the payment — not to operate the software, live with the consequences, or absorb the feedback of real users over real time.
The result is predictable: software that passes UAT, gets deployed, and quietly degrades. Workarounds accumulate. The client hires another agency to fix what the last one built. The cycle repeats.
We believe the only way to build software that actually works at operating depth is to own what you build, run it in production, handle support, watch customers leave when you get it wrong, and watch them stay — and pay — when you get it right.
That alignment of incentives is the holding model. Every product Dal Dom holds, Dal Dom operates. The people who built it are the same people who run it.
The Architecture
Each product was built for a specific problem. Together, they point toward something larger.
This convergence is not forced. It emerges from the fact that all four problems — property management, workforce culture, procurement, and software verification — are problems that every serious operating company in the Saudi economy faces simultaneously. The products were built in parallel, for the same domain.
The Doctrine
These are not values on a wall. They are operational constraints. Every product decision traces back to at least one of them.
We don't design what we think the market wants. We operate in the market first, identify the precise failure, and then build the smallest system that eliminates it. The product is discovered through operations, not imagined before them.
Borrowed from the SATE doctrine: software must prove what it does, not describe it. We apply this to our products (observable outcomes, not feature lists), our AI systems (signed evidence, not logged guesses), and our customer relationships (retention data, not testimonials).
We build fewer products and go deeper into each one. Maktabi's outreach engine has 208 service components — not because we like complexity, but because the problem of converting a Saudi real estate lead via WhatsApp is genuinely complex. Shallow solutions don't survive contact with real operations.
Every interface, every AI prompt, every legal text, every error message must be designed in Arabic first or designed to be genuinely equivalent — not translated as a second pass. A translated product carries the logic of the original language. A native product carries the logic of the actual user.
ZATCA e-invoicing, Saudi VAT, Hijri calendar, 360dialog WhatsApp Business API compliance, and Saudi data residency requirements are not edge cases. They are the operating environment. They are built into the architecture, not retrofitted onto it.
Dal Dom's holding structure is not administrative convenience. It exists to enforce a consistent quality standard across products that might otherwise drift independently. The holding discipline — shared architectural patterns, shared compliance posture, shared AI infrastructure — is what allows four products to feel like they belong to the same family.
We think in years about product direction but execute in days. Our AI systems update strategy weights daily. Our products ship weekly. Our infrastructure decisions are made for the 10-year version, not the 10-day version. The discipline is holding both timeframes simultaneously without letting the urgency of one corrupt the integrity of the other.
The Question We Ask
Every product decision, every architectural choice, every new feature at Dal Dom gets filtered through this question. If the answer is yes, we invest in it properly. If the answer is no, we deprioritise it regardless of how quickly it could be built.
Most companies optimise for what matters in five weeks. We believe that mismatch — between the timeframe of real value and the timeframe of development decisions — is the primary reason most software doesn't age well.
Proper multi-tenancy architecture. Costs weeks. Saves years.
AI that adapts to the specific audience, not a generic script.
Arabic-native design. The market isn't going anywhere.
A feature requested by one customer that contradicts the product model.
A quicker but structurally incorrect database schema.
An undocumented edge case accepted as "shipped" because it passed UAT.
We take on select external engagements when the problem fits and the partnership is right. Start with a quote request.