Client / Sector
DZOS — ERP and business operating system
Market
Algerian SMEs: distributors, retailers, workshops, service firms
Engagement
Product design, design system, marketing site, engineering
Status
Shipping, 2026
The situation
The Algerian mid-market runs on a stack nobody designed: a spreadsheet for stock, a paper carnet for the depot, a till that does not talk to either, and an accountant who receives all of it in a plastic folder at the end of the quarter. It works until the business has two warehouses, or starts producing as well as reselling, and then the gap between what the manager believes is in stock and what is actually there becomes the single largest source of lost money in the company.
International ERPs answer this on paper and fail on contact. They are sold as monthly subscriptions in foreign currency, they assume permanent connectivity and a central cloud, and their document vocabulary belongs to another jurisdiction. A distributor in Setif or Oran is being asked to rent, indefinitely, software that stops working when the ADSL line does and that stores their entire commercial position on a server they cannot point at.
DZOS was built against those objections rather than around them: one application covering commerce, distribution, services, warehousing, production, inventory and finance, available either as desktop software under a one-time licence or as a local cloud running on the customer's own infrastructure. We built the whole surface — the design system, the in-app product, the business intelligence layer and the editorial marketing site that has to sell an ERP without sounding like one.
What made this hard
Seven trades, one data model
A distributor moving cartons between depots, a workshop consuming raw material into a production order, and a shop selling a unit at the till are, underneath, the same event: stock changed and value moved. Modelling them as seven separate features would have produced seven separate versions of the truth. Finding the shared primitive without flattening what makes each module useful was the central design problem.
Offline is the operating condition, not an edge case
Power cuts and dead connections are not exceptions to plan for; they are Tuesday. A till that refuses to sell because a server is unreachable is worse than a paper receipt book. That reality had to be a first-class architectural constraint from the first sprint, because retrofitting local-first behaviour onto a cloud-shaped application is not a refactor, it is a rewrite.
Software people buy once
A one-time desktop licence is what the market wants and it removes the mechanism most software companies rely on to keep customers current. There is no monthly leverage, no forced upgrade path, and often no live connection to check anything against. Licensing, updates and database migrations all had to work for a machine that may be offline, may be years behind, and must never be bricked by an update it did not ask for.
Numbers an accountant will accept
An ERP's finance module is judged by whether the figures survive contact with the person who files them. Documents have to carry through the chain without being re-keyed, totals have to agree across modules by construction rather than by reconciliation, and a corrected inventory count has to leave a trace rather than silently rewriting history.
Bilingual density, in both directions
French and Arabic in an ERP means dense data tables, numeric columns and long document labels flipping direction wholesale. Arabic is not a translation layer over a left-to-right layout; it is a different layout of the same information. Doing it as a late-stage patch produces a product that is usable in one language and merely tolerable in the other.
How we approached it
We started from the ledger, not the screens. Before designing a single module we defined the small set of events the whole system is made of — a stock movement, a document, a monetary entry — and made every module a different lens on those events. That is what allows the inventory a manager sees at the till and the inventory the finance module values at cost to be the same number rather than two numbers that usually agree.
The second decision was to design the system before the features. Seven modules built screen by screen become seven products with a shared logo. A token-level design system, with direction-agnostic layout rules baked in from the start, is what keeps a point-of-sale screen and a general ledger recognisable as one application — and it is what made the Arabic surface a property of the system rather than a project of its own.
Domain model and the shared event
We mapped the seven modules onto a common core: what a movement is, what a document is, and how value attaches to both. This is where multi-warehouse distribution and production stopped being separate products and became different sequences of the same primitives, which is the reason a transfer between depots and a raw-material consumption reconcile against each other without a nightly job.
Design system and the bilingual layout foundation
We built the component and token layer first: tables, forms, KPI tiles, document layouts, and the direction-agnostic spacing rules that make the Arabic surface a switch rather than a fork. Every module built afterwards inherited that vocabulary, which is why the density feels intentional instead of accumulated.
The operational modules
Commerce, distribution, warehousing, inventory and point of sale were built against the shared core, with the till treated as the hardest case: fast, keyboard-driven, and required to keep working when nothing else does. Services and production followed, reusing the same movement and document primitives rather than introducing parallel ones.
Finance and business intelligence
The finance module closes the loop between operational events and monetary position, and the BI layer sits on top of it: clean KPI tiles, period-over-period comparison and exportable reports. The design constraint here was restraint — a manager needs three numbers they trust more than forty they have to interrogate.
Two deployment shells and the marketing site
The same application was packaged as a desktop build for the one-time licence and as a local cloud deployment on the customer's own server, with the database local in both cases. Alongside it we built the editorial marketing site that has to explain an operating system for a business to someone who currently runs one in a spreadsheet.
What we shipped
Operations
- Multi-warehouse stock with transfers tracked as movements
- Point of sale built for speed and for working without a connection
- Distribution flows from order through delivery to invoicing
- Production orders that consume inputs and yield finished stock
- Service jobs modelled alongside goods, in the same documents
- Inventory counts and corrections that leave an audit trail
Finance and intelligence
- Finance module fed by operational events rather than re-entry
- KPI tiles designed to be read in five seconds
- Period-over-period comparison on every headline figure
- Exportable reports for the accountant's own workflow
- Valuation that reconciles with physical stock by construction
- Document chains that carry data forward without re-keying
Platform and delivery
- Desktop application under a one-time licence, offline-friendly
- Local cloud deployment on the customer's own infrastructure
- Local relational database in both deployment shapes
- Unattended, idempotent database migrations on update
- Full French and Arabic interfaces, right-to-left included
- Shared design system across all seven modules
Engineering decisions
The choices that shaped the build, and what each one traded away.
One application core, two shells
The desktop build and the local cloud deployment are the same application; what differs is where the database sits and how the client reaches it. That kept us from maintaining two products with diverging feature sets, which is the usual fate of desktop-plus-cloud offerings. The trade-off is that the entire codebase has to assume the database is close and single-tenant: none of the shortcuts a central SaaS enjoys are available, and capabilities that would be trivial with a central server, such as fleet-wide analytics or remote support, have to be designed as explicit, opt-in features rather than assumed.
Stock is an append-only movement journal, not a quantity column
Every transfer, sale, production consumption, return and inventory correction is an entry; a quantity on hand is derived from them. This is what makes multi-warehouse balances, historical valuation and 'why is this number wrong' investigations answerable at all — you can replay how the figure came to be rather than trusting a field somebody overwrote. The trade-off is read cost: naive listing pages would recompute history on every page load, so balances have to be materialised and kept warm, and that cache becomes a thing you are responsible for keeping honest.
A relational database on the customer's own machine
We kept a real relational engine rather than an embedded document store, because stock, documents and finance need transactions that span all three and constraints that hold regardless of application bugs. Shipping and upgrading a database on a machine we do not administer is the price. It made migrations a product feature rather than a deployment step: they have to be idempotent, unattended, safe to run on a version several releases behind, and incapable of leaving a client's business unable to invoice on a Monday morning.
Direction-agnostic layout as a system rule
Arabic support was implemented at the token and component level using logical layout properties, so direction is a document-level switch rather than a set of per-screen overrides. Any module built afterwards is bilingual by default, which is the only sustainable answer when there are seven of them. The cost was paid up front, before a single business screen shipped, and it constrains the design vocabulary — layouts that depend on a fixed left-hand rail or hard-coded directional spacing simply are not available to us.
Optimistic local writes at the till, reconciled behind the screen
The point of sale commits locally and confirms visually before anything else happens, because a cashier queue is not a place to discover latency. Everything else in the application is allowed to be slower and more careful. The trade-off is that the till owns a window where the local state is ahead of the rest of the system, so the reconciliation path and the failure messaging around it needed more design attention than the happy path ever did.
The outcome
DZOS ships as a single application covering the operational spine of a mid-sized business: what is in each warehouse, what moved and why, what was sold and produced, what it is worth, and what the position looks like against the same period last year. The value is less in any individual module than in the fact that the till, the depot and the finance screen are reading the same events instead of three separate approximations of them.
The deployment choice is the part of the offer that departs most from the category norm. A business can buy the desktop edition outright and run it on machines it owns, or stand the platform up as a local cloud on its own server, and in neither case does its commercial data leave the premises or depend on a connection staying alive. For a market that has been asked to rent foreign software in foreign currency, owning the thing outright is not a feature detail; it is the reason the conversation happens at all.
Alongside the product, the editorial marketing site gives DZOS a public face that argues the case in the language the buyer uses — modules, deployment, ownership — rather than in the abstract vocabulary ERPs usually reach for.
7
Modules
Commerce, distribution, services, warehousing, production, inventory and finance built on one shared data model.
2
Deployment models
A desktop application under a one-time licence, or a local cloud running on the customer's own server.
FR / AR
Interface languages
French and Arabic, with Arabic handled as a right-to-left layout rather than a translated overlay.
One-time
Desktop licence model
The desktop edition is purchased outright rather than rented on a monthly subscription.
Honestly
Choosing local-first and one-time licensing means giving up the things a subscription cloud gives you for free: automatic updates everyone actually receives, telemetry that tells you which screens are used, and the ability to fix a customer's problem before they notice it. We accepted all of that, because the alternative was a product the market would nod at and not buy. It does mean support is a deliberate discipline — updates have to be desirable rather than mandatory, and every release has to assume the customer running it is several versions behind.
The next frontier is the one every ERP eventually reaches: making the data explain itself. Seven modules feeding one event stream is exactly the substrate an assistant layer needs, and it is the direction the category is moving. The constraint is that it has to be earned by the data model being right first — an assistant on top of numbers that do not reconcile is a faster way to be confidently wrong.
Frequently asked
What is the difference between an ERP and accounting software?
Accounting software records what already happened, in monetary terms, usually after the fact. An ERP like DZOS records the operational events as they occur — a stock movement, a delivery, a production order, a sale at the till — and the financial position is derived from them. That is why the stock figure and the valuation agree by construction instead of being reconciled at the end of the month.
Can an ERP work offline or without a permanent internet connection?
Yes, if it is designed that way from the start. DZOS runs with the database local to the business, either as desktop software or as a local cloud on the company's own server, so operations such as the point of sale keep working when the connection does not. Retrofitting this onto a cloud-first application is generally a rewrite rather than a configuration change.
Is it better to buy business software once or pay a monthly subscription?
It depends on where the risk sits for you. A one-time licence means the business owns the tool and its data outright and is not exposed to currency movements or renewal decisions; a subscription buys continuous updates and support. DZOS offers the one-time desktop licence because that is what the Algerian mid-market asks for, and a local cloud option for companies that want multi-user access across a site.
Can an ERP be used in Arabic as well as French?
It can, but only if right-to-left is treated as a layout concern rather than a translation task. In DZOS the Arabic interface is a direction switch at the system level, built into the component and spacing rules from the beginning, so dense tables, document layouts and numeric columns behave correctly in both languages instead of one being a compromised version of the other.