Deployed Realities is DarDev's public commitment that what we describe on dardev.net is software we actually run not slideware, not vaporware, and not roadmap dressed up as today's product. When we say Hesabi, DarDevLab, or our Unified Mailer stack is operational, we mean our team depends on it in production.
The phrase appears across our solutions pages because buyers in Tunisia and MENA have seen too many demos that never survive first contact with real users, real compliance, or real on-call pages. We chose the opposite posture: ship, operate, learn, and publish honestly about limits.
Live SaaS versus platform pipeline
DarDev Solutions splits into two buyer motions. Solutions Hesabi for Tunisian SME finance, DarDevLab for cloud-native learning, EscaHire on waitlist for recruitment are market-facing products with their own domains and support expectations. Platform products Workspace IAM, DarDevCDE, DarDevOps, Observability are the engineering pipeline we use to build and run those solutions: Authorize, Develop, Deploy, Observe.
Both sides share Kubernetes-native infrastructure on stacks we maintain, including the Unified Mailer (Twenty CRM, Listmonk, Stalwart on send.dardev.net) documented on this news site. That dogfooding is intentional: if a pattern is not good enough for our CRM and campaigns, we do not sell it as enterprise-grade.
What we will and will not claim
- We say waitlist when a product is not GA EscaHire is invite-only beta, not general availability.
- We say Tunisia-only when Hesabi has not certified another country’s fiscal rules.
- We describe integrations we operate GitLab, Portainer, Prometheus, Grafana not every logo that fits a slide.
- We publish release notes and architecture articles here when stacks go live, not only press releases.
Built in Tunis, honest about geography
We are headquartered in Tunis. Hesabi encodes Tunisian VAT, TTN-oriented workflows, and TEJ reporting realities because that is the market we serve today. DarDev Services consults across MENA on cloud and DevOps, but we do not blur product availability lines consulting reach is not the same as product regulatory coverage.
Regional growth for us means exporting engineering discipline and bespoke delivery, while each SaaS product expands only when compliance and support are ready. That slower map is part of Deployed Realities too.
How this shows up in delivery
Internal projects must pass the same gates as client work: identity via Workspace patterns, builds through DarDevOps pipelines, observability before we call a service production. Failures feed back into DarDevLab curricula and Hesabi UX our education and finance products improve from incidents we actually experienced.
For enterprise buyers, Deployed Realities means proposals reference running systems you can inspect crm.dardev.net, mail.dardev.net, news.dardev.net not hypothetical reference architectures. Read how we dogfood our stack and how solutions versus platform products serve different purchasing paths for the full picture.
Why customers should care
Procurement teams risk signing vendors whose features exist only in sales decks. Deployed Realities gives you a simple due-diligence checklist: ask where the software runs, which subdomain serves production traffic, and what happens when an integration is marked beta. We answer with URLs and architecture notes including public articles on our mailer stack and CRM wiring.
For Tunisian SMEs evaluating Hesabi, the same standard applies: TTN and TEJ capabilities are described in context of what we ship and what is on roadmap, with accountant-facing honesty. For training buyers, DarDevLab labs reflect clusters and tooling we maintain, not abstract certification trivia.
Enterprise services buyers get a similar contract: DarDev Services proposals reference patterns proven on our own VPS and client clusters Kubernetes, observability, and CI/CD before we recommend them at scale. That reduces bait-and-switch between pilot and production.
News articles on news.dardev.net follow the same rulebook including this one. When we publish guides about TTN or GitLab pipelines, they reflect production decisions and linked runbooks, not generic SEO filler. That consistency is how Deployed Realities scales beyond a single product page into a company-wide documentation culture.
Questions to ask any vendor
- Show production URL and on-call owner for the module you are buying.
- Clarify regional compliance scope in writing not only on a map slide.
- Ask what happens when an API integration fails at month-end close.
- Request documentation written after launch, not before prototype.
We publish those answers on dardev.net, hesabi.tn, and this news site so prospects never depend on a single sales call.
Is Deployed Realities a marketing slogan?
It is an engineering policy. Product and sales copy must match deployed behavior. Waitlist, beta, and regional limits are stated explicitly.
Which DarDev products are live today?
Hesabi and DarDevLab are operational SaaS offers. Platform modules and EscaHire vary by module EscaHire remains waitlist. See dardev.net/solutions for current status.
Do you use your own mail and CRM stack?
Yes. Twenty CRM, Listmonk campaigns, and Stalwart delivery from send.dardev.net power our outreach and product lists documented in our Unified Mailer article.
How does this affect partners and accountants?
We prefer partners who review our public docs and correct us. Hesabi workflows are designed with Tunisian accountants in mind; we document compliance changes as they ship.
