InfraDZ
The premier AI business platform, built for faster growth
An ERP whose assistant does the work: InfraDZ answers questions and drafts plans from a company's own pipeline and operations data, in French, English or Arabic.
InfraDZ is the AI-native ERP: sales pipeline, team management and operations automation in one trilingual (FR/EN/AR) platform designed for modern Algerian businesses.
The differentiator is the built-in AI assistant — ask it to generate a Q4 cash-flow plan or automate customer payment reminders, and it acts across your real business data.
We built the platform end-to-end: the editorial brand and marketing site, role-based product surface, AI assistant integration, and a self-serve onboarding with demo booking.
Where this started.
Business software in Algeria has historically been sold, installed and configured by a person who visits your office. That model produces long sales cycles, high switching costs and a market where most companies have never evaluated a business platform on their own terms — they have simply been given one. Self-serve signup is rare enough that it changes who the product can reach: a founder can look at it on a Tuesday night without booking anything.
At the same time the category itself is moving. An ERP has always been a system of record — you put data in, and later you read it back in the shape of a report you had to know how to ask for. What companies actually want is the answer: what does the last quarter say about cash next quarter, which customers have not paid, who on the team is carrying too much. That gap between recorded data and usable answers is the space InfraDZ was built for.
InfraDZ unifies sales pipeline, team management and operations in one trilingual platform, with an AI assistant that works across the company's real records rather than sitting beside them as a chatbot. We built it end to end: the editorial brand and marketing site, the role-based product surface, the assistant integration, and the self-serve onboarding with demo booking for teams that still want the conversation.
What actually made this hard.
An assistant that acts on real data inherits real permissions
The moment an assistant can read a company's records, the question stops being 'is the answer good' and becomes 'was this person allowed to ask'. Role scoping cannot live in the interface layer, because the assistant is a second door into the same data. Every capability the assistant has needed to resolve against the same authorisation the product surface uses, or the AI feature would quietly become a privilege escalation.
A plan that is invented is worse than no plan
Asking a language model for a cash-flow projection is trivially easy and dangerously wrong when the numbers come from its imagination rather than the company's ledger. Grounding every answer in the tenant's actual records — and being clear about what the assistant could not find — mattered more than making the assistant sound fluent. A confidently fabricated figure in a finance context destroys the trust the whole product depends on.
Three languages, one canonical set of records
The interface is French, English and Arabic, with Arabic laid out right to left, but the data underneath is one schema. The assistant has to answer in the language the user is working in while reasoning over records that carry no language at all, and the product has to stay coherent when a team mixes languages across the same company account.
Self-serve onboarding for a category that is normally installed
An ERP with an empty state is an unanswerable question: nothing works until data exists, and nobody imports data into a product they have not seen working. The first session had to teach the product rather than present it, and the assistant turned out to be part of the answer: being able to ask the system what it can do is a better tutorial than a tour.
Automation people are willing to leave running
Automating customer payment reminders means a machine sends messages in the company's name while nobody is watching. That is a trust threshold quite different from generating a report. The automation surface had to be legible and reversible — visible before it runs, inspectable after — or serious users would simply never switch it on.
How we ran it.
We treated the assistant as a client of the platform, not as a privileged component inside it. It reaches the business data through the same authorised interfaces the product surface uses, which means role scoping, validation and business rules apply identically whether a request came from a click or a sentence. That single decision removed an entire category of security and consistency problems before they could exist.
The rest of the work was making an all-in-one platform feel small. Pipeline, team management and operations in one product risks a menu nobody wants to read, so the surface is resolved per role — you see the modules your job needs — and the assistant sits across all of them as the shortcut for everything you did not want to go looking for.
Product architecture and role scoping
We defined the modules, the roles and the permission matrix that connects them, treating the matrix as data the application resolves rather than as conditions scattered through the code. This became the contract the interface, the API and later the assistant all answer to, which is what made it safe to add an AI layer at all.
Brand and marketing surface
In parallel we built the editorial brand and the marketing site: positioning the platform as an AI-native business system rather than another module list, and wiring the two entry paths — immediate self-serve signup, and demo booking for organisations that want to be walked through it.
The core platform
Sales pipeline, team management and operations were built on one relational core with a trilingual interface and a right-to-left Arabic surface handled at the layout level. Multilingual parity became a release condition rather than a follow-up task, because a partially translated ERP is not usable in the untranslated language.
The assistant layer
We integrated the assistant as a tool-using client over the authorised API, so it retrieves the company's actual records to answer questions, drafts plans from them, and proposes automations. Anything that changes state is surfaced as a proposed action for a person to approve rather than executed silently.
Deployment and release discipline
The platform runs as containerised services with a database, cache and connection pooling layer, and a staging environment that mirrors production. For a system a company invoices from, a release that has not been rehearsed against a realistic copy is not a release; it is an experiment on someone's business.
Everything that shipped.
Business platform
- Sales pipeline with stages, ownership and follow-up
- Team management with role-scoped access
- Operations tracking unified with the commercial side
- A product surface that resolves per role instead of one universal menu
- Trilingual interface in French, English and Arabic
- Right-to-left Arabic layout handled at the system level
AI assistant
- Questions answered from the company's own records, not from model memory
- Drafted plans, such as a forward cash-flow view, built from real figures
- Automation proposals for recurring work like payment reminders
- State-changing actions surfaced for human approval before they run
- Answers returned in the language the user is working in
- Access resolved against the same permissions as the interface
Onboarding and platform
- Self-serve signup with no sales call required
- Demo booking retained for larger organisations
- Editorial marketing site and brand system
- Containerised deployment with a mirrored staging environment
- Relational core with caching and pooled database connections
- Trilingual content parity enforced as a release condition
The calls we made, and what they cost.
Every decision here bought something and gave something up.
The assistant is a client of the API, never of the database
Every capability the assistant has goes through the same authorised interfaces the product surface calls, so permissions, validation and business rules are enforced in exactly one place. It also means the assistant cannot invent a capability the product does not have: extending what it can do requires extending the API first. That is slower than letting a model query the database directly, and it is the entire reason the AI layer does not become a shadow product with its own security model and its own idea of what a valid record looks like.
Read freely, write by proposal
The assistant can retrieve, summarise and draft without ceremony, but anything that changes state — sending reminders, updating records, enabling an automation — is presented as a proposed action a person confirms. We lose some of the magic of a system that just does it, and we accept that trade deliberately: in a platform that speaks to a company's customers in the company's name, an action nobody approved is a liability no amount of accuracy compensates for.
Grounding before fluency
Answers are assembled from retrieved records rather than from the model's prior, and when the data is not there the assistant says so instead of filling the gap. In a finance context a plausible number is more dangerous than a missing one, because a missing number gets checked and a plausible one gets used. The trade-off is that the assistant is more constrained than a general chatbot and will decline questions it has no data for, which is the correct behaviour for a system of record, and it took explicit design work to make declining feel helpful rather than broken.
Roles as data, not as conditionals
The modules, actions and fields a role can reach are resolved from a permission matrix at load time, so there is one app shell rather than a fork per role and one place to answer 'who can see this'. It is harder to trace by reading a single file than a scatter of inline checks, so the matrix has to be treated as a first-class artefact with its own tests. The payoff is that the assistant, the interface and the API all consult the same source of truth instead of three drifting approximations of it.
Trilingual parity as a release gate
French, English and Arabic strings ship together or the release does not ship, and Arabic direction is handled through logical layout properties rather than per-screen overrides. Making translation a gate slows individual features down, visibly. The alternative — shipping in one language and back-filling the others — produces a product where one third of the audience is permanently using last month's version, which for a platform whose users mix languages inside the same company account is not a compromise anyone would accept.
Where it landed.
InfraDZ runs as a working platform where the pipeline, the team and the operational side of a business live in one place, and where the assistant is the fastest way into any of it. The practical shift is in who can get an answer: a manager who would previously have asked someone to build a report can ask the system directly, and get a response grounded in the company's actual records rather than in a spreadsheet somebody exported last month.
Self-serve signup is the structural difference between how InfraDZ is bought and how this category is normally sold. A company can create an account and see the product working without negotiating anything, with demo booking still there for organisations that want to be walked through it. For a category that is normally sold in person, that is a structural change to how the product reaches its market, and it forced a product discipline that installed software never needs: the first ten minutes have to be self-explanatory.
The trilingual surface matters for the same reason. A platform used by a mixed team is only as good as its weakest language, and treating French, English and Arabic as equal releases rather than a primary plus two translations is what lets a company standardise on it internally.
The assistant is the newest part of the platform and the part we are most deliberately conservative about. Keeping it behind the authorised API and behind human confirmation for state changes means it is less impressive in a demo than an agent that just acts, and it is the reason we would be comfortable leaving it switched on in a company that invoices from this system. As the API surface grows, the assistant grows with it, which is a slower curve than a model with database access but a far more predictable one.
The honest constraint is that an AI-native ERP is only as good as the data a company actually puts in. The assistant cannot plan cash flow from records that were never entered, which makes onboarding and data capture the real determinant of value, not the model. That is where the next work sits: making the boring part — getting a business's operational reality into the system — feel as effortless as asking the assistant a question does.
Questions about this project.
In InfraDZ it reads the company's own pipeline, team and operations records to answer questions, draft plans such as a forward cash-flow view, and propose automations like customer payment reminders. It is not a general chatbot bolted onto a dashboard; it works through the same authorised interfaces as the product, so it only ever sees what the person asking is allowed to see.
It is if you constrain it correctly. Our approach is that the assistant reads freely within the user's permissions but cannot change state on its own: anything that sends a message or modifies a record is surfaced as a proposed action for a person to approve. Answers are also grounded in retrieved records rather than generated from model memory, so a missing figure is reported as missing instead of invented.
Yes, and InfraDZ ships French, English and Arabic together as a release condition rather than adding translations later. Arabic is handled as a right-to-left layout at the system level, not as text swapped into a left-to-right design, which is what keeps dense tables and forms usable in both directions.
With InfraDZ you can — signup is self-serve, so a team can create an account and use the platform without a sales cycle. Demo booking is still available for larger organisations that want to be guided through it, but it is an option rather than a gate, which is unusual for this category in the Algerian market.
