Mission
To build software that
earns its place.
Not software that gets deployed and forgotten. Not software that solves a demo problem. Software that teams rely on, customers pay for without question, and operators are proud to run.
"We build operating companies, not products.The Dal Dom Operating Principle
We understand markets by operating in them, not studying them.
We ship software that we depend on, and then we sell access to it."
In Practice
We enter markets before building for them
Maktabi wasn't built because someone read a market report. It was built because the people who built it managed properties, collected rent, handled maintenance, and negotiated with agents, and found every existing tool inadequate. The product came from operations, not observations.
We run what we ship
Every Dal Dom product is a live, revenue-generating, customer-serving software group. We deal with production incidents, customer complaints, billing edge cases, and regulatory changes. This forces a quality standard that no freelance brief or sprint board can enforce. Pain is the best product manager.
We don't take shortcuts that create debt we can't pay
Multi-tenancy, audit trails, proper queue architecture, region-aware billing, append-only evidence ledgers, ZATCA-compliant e-invoicing: these are expensive to build correctly and nearly impossible to retrofit. We pay the cost upfront. The products that result are harder to compete with, not easier to build. Bilingual and multi-currency come standard on top of that foundation.
Three ways to work with us
Commission us to build and hand it over, and you own the software and run it. Hire us to consult and advise on what you are building. And when we like the idea and the team, we love coming in for shares, as an equity partner, a joint venture, or a co-founder, building alongside you for the long run. The shares route is the one we are happiest to take, but it never gates the other two. We build for clients who will run the software themselves, never for resale or work that competes with our own portfolio.
We apply the SATE standard to our own work
Our software execution certification product, SATE, exists because we believe software must prove what it does, not describe it. We apply that doctrine internally. Our AI systems don't guess. Our APIs don't hallucinate. Our billing doesn't round incorrectly. When we say it works, we mean we have evidence.
We build for the market that exists, not the one we prefer
Each market we serve has its own regulatory environment, languages, payment infrastructure, trust culture, and relationship between technology and business. We don't impose foreign assumptions. We design for what's actually in front of us, wherever that is.
What We Won't Do
The other half of a mission is what you refuse.
Build for markets we don't understand
Entering a new vertical requires operational experience in it first. We don't start with the code. We start with the problem.
Pass off configurable services as a product
We advise and consult, and we are glad to. What we won't do is dress up a billable retainer as a product. Our products are opinionated systems built on a clear model of how the domain should work, not professional services with a logo on them. When we build for a client, we hand over real, operable software they own and run.
Accept "working" as sufficient
Working is the baseline. We hold ourselves to predictable, provable, and operable at scale. We build our own products to the same standard we build yours, and we verify it with SATE.
Build for acquisition metrics
We don't optimize for vanity growth, DAU theater, or pitch-deck narratives. We optimize for product quality, customer retention, and long-term operational health.
Treat compliance as something we bolt on later
ZATCA e-invoicing, append-only audit ledgers, and region-aware billing are designed into the architecture from the first commit. We don't ship money or tax code we can't prove, and we don't retrofit compliance after a market says no.
Understand the concept that drives everything.
Why a holding structure? Why operate the products we build? What is the logic that unifies all seven products?