Sector
LegalTech · AI SaaS
Market
Algeria and the Maghreb
Engagement
Full product — strategy, speech and AI pipeline, RTL product design, SaaS engineering
Status
In production · 2026
The situation
Algerian legal practice still runs on paper habits translated badly into software. A lawyer drafts a petition (aridha) or a court memorandum (moudhakkira) in a generic word processor, keeps client files in folders named by hand, tracks hearing dates in a paper diary, and rewrites the same procedural boilerplate for the hundredth time. The document itself is not the hard part — the lawyer already knows what to say. The hard part is the hour spent typing it in Arabic, in the shape a given court expects, with the right parties, the right articles and the right closing formulas.
The language situation makes off-the-shelf tools worse rather than neutral. Arabic legal drafting is right-to-left, but case references, dates, article numbers and French procedural terms are left-to-right and appear mid-sentence. Lawyers speak Algerian Arabic, write Modern Standard Arabic, and switch to French for whole clauses depending on the jurisdiction and the era of the file. A product that treats Arabic as a translation of an English interface fails on the first paragraph — mirrored margins, broken bidirectional runs, seals that land on the wrong side of the page.
Mouhami started from the observation that lawyers dictate all the time already: to a secretary, to a phone recorder, to themselves while driving. The product opportunity was not to invent a new behaviour but to give the existing one an output. Speak the facts of the case; get a structured, exportable, signable document. Everything else in the platform (clients, matters, templates, hearings, invoices) exists so that the dictation has somewhere to live.
What made this hard
Algerian Arabic is not the Arabic speech models were trained on
Public speech models are benchmarked on clean broadcast Modern Standard Arabic. Real dictation is Algerian darija with French loanwords, legal terms of art, party names and article numbers, which are exactly the tokens a model must not guess at. We had to treat transcription accuracy as an engineering variable to be measured on real audio, not a vendor claim to be trusted.
A five-minute dictation breaks assumptions everywhere
A real petition dictation runs several minutes of audio. That single fact invalidates streaming-first designs, default HTTP timeouts, and CDN-proxied endpoints, each of which quietly caps a request long before a long recording finishes processing. Every layer between the phone and the transcription process had to be re-examined against the length of an actual dictation.
The document has to look like a filing, not like a web page
Lawyers judge the product on whether the exported file is usable in front of a clerk. That means true A4 pagination, correct RTL margins, headers and closing blocks in the expected order, and a signature and seal placed where a court expects them — inside DOCX as well as PDF, because half the profession still edits the Word file before filing.
Multi-tenancy in a profession built on confidentiality
Firms share a platform but must never share a byte. Client identities, matter notes and dictation audio are privileged material. Any tenancy model that derives the firm from something a client can send is one crafted request away from a disclosure incident, so the boundary had to be structural rather than checked.
One editor, two very different runtimes
Lawyers use the desktop web app in the office and a phone between hearings. The best native rich-text components for React Native require a custom development build and do not run on the web at all, so maintaining two editors would have meant two pagination engines, two RTL implementations and two export paths drifting apart.
How we approached it
We built Mouhami as a product with a spine: a domain model of legal practice first, then an interface on top of it. Before writing feature code we mapped the legal domain into explicit modules — firm, member, client, matter, document, template, dictation, invoice, time entry, notification — and made each one a bounded piece with its own commands and queries rather than a set of CRUD screens. That choice is why dictation could later be added as a capability of a document instead of a bolt-on feature.
The second principle was design-first. An early round of incremental UI work was rejected outright: the screens were changing while the experience was not. We stopped coding, designed the entire journey as a full frame set — onboarding, sign-in, home, voice capture, AI drafting, the A4 editor, documents, templates, clients, cases, agenda, invoices, settings, paywall — reviewed it as a whole, and only then rebuilt the interface against it. Fidelity to those frames became the acceptance bar, not a suggestion.
Domain design before screens
We wrote the domain contract for a legal practice and turned it into a clean-architecture backend with explicit commands and queries. Firms, members, clients, matters, documents, templates, dictations, invoices, time entries and notifications were modelled as separate concerns, so that a change to billing never reaches into case files.
The platform and its three surfaces
One API serves a web application, an internal admin console and a native mobile app. Building all three against the same command surface forced the API to be genuinely complete rather than shaped around whatever the web client happened to need, and kept token handling, tenancy and permissions in a single place.
Arabic-first interface design
We designed the whole experience RTL-first with a navy and gold identity and Arabic typefaces chosen for legal reading, not for logos. Every screen was reviewed at real phone width rather than stretched browser width, because RTL layouts fail in ways that only appear when the column is narrow.
Speech, measured rather than assumed
We stood up self-hosted transcription on a dedicated node separate from the application server, then benchmarked candidate models on real Arabic audio for both speed and word error rate. The results overturned our own estimates: the largest model ran slower than real time on CPU and was simply not deployable, while a turbo variant beat the mid-size model on both accuracy and speed.
Drafting, editing and export
The transcript feeds a drafting step that maps spoken facts into the structure of the chosen document type, then lands in an A4 editor the lawyer can correct. Export produces DOCX and PDF with signature and seal placement, because the file has to survive the last mile between the office and the court.
What we shipped
Voice to document
- Record a dictation from web or phone and upload it as one batch job
- Self-hosted Arabic and French transcription on dedicated infrastructure
- AI drafting that maps a spoken account into the structure of the chosen document type
- Templates for petitions, memoranda, powers of attorney and formal notices
- Firm-wide templates alongside global seeded ones
- A4 editor for correcting the draft before it leaves the platform
Practice management
- Client records with documents attached to the right file automatically
- Matters and case files as first-class entities, not folders
- Hearing agenda with advance reminders
- Time entries and invoicing in dinars
- Role-based access for firm owner, lawyer and legal assistant
- Notifications tied to firm activity rather than to a single device
Interface and platform
- RTL-first Arabic interface with French throughout
- Web application, native mobile app and internal admin console on one API
- Onboarding carousel and guest browsing before the sign-in wall
- Authentication wall that gates write actions rather than the whole product
- DOCX and PDF export with signature and seal placement
- Paywall designed as part of the journey rather than bolted on at the end
Engineering decisions
The choices that shaped the build, and what each one traded away.
Batch transcription instead of streaming
We rejected a streaming speech architecture and made dictation a batch job: record, upload, transcribe server-side, return the text. Streaming would have required persistent secure sockets from every client, which in practice means certificate and network problems on office wifi and mobile data, and a client that has to handle partial results. The trade-off is that the lawyer waits for a complete transcript instead of watching words appear. That is acceptable on a document the profession reviews as a whole, and it keeps the clients simple and the transport out of the failure list.
Long audio forced a timeout audit at every layer
The original transcription client carried a two-minute request timeout, which silently killed any dictation longer than a few minutes of audio, which is to say any normal petition. Separately, routing the transcription endpoint through a proxying CDN imposed an origin response ceiling shorter than a real dictation, so every genuine recording failed while short test clips passed. We made the timeout configurable with a generous default and took the transcription endpoint off the proxy path. The trade-off is that failure now surfaces slowly: a job that is genuinely stuck holds a request open for minutes before anything reports it, so liveness had to move into the job itself instead of being a side effect of a short timeout. On a speech product the request timeout is a product parameter, not an infrastructure default.
Tenancy derived from the token, never from the request
The firm identifier is read from the authenticated token on every command and query, and is never accepted as a request parameter, so there is no code path where a client can name the firm whose data it wants. It costs some convenience: internal tooling and admin operations need their own explicit path rather than passing a firm id, and every query carries the tenant filter. For privileged legal material that is the right price for making cross-tenant leakage structurally impossible rather than a review item.
One editor in a web view across web and native
The strongest native rich-text component for React Native only runs in a custom development build, with no web target. Rather than maintain two editors, we implemented the A4 editor once as a web-view document surface that runs identically in the browser preview and inside the mobile app. We accept a small amount of bridge work and slightly less native feel in exchange for a single pagination engine, one RTL implementation and one export path, which on a document product is where the real complexity lives.
Measure the model on the hardware you will actually run
We benchmarked three transcription models on Arabic audio on the exact CPU profile we intended to deploy. Our pre-benchmark estimate of throughput was wrong by a wide margin, the largest and most accurate model turned out to run slower than real time and was eliminated, and the turbo variant beat the mid-size model on both axes at once. The trade-off we accepted is a marginally higher error rate than the largest model in exchange for a dictation that finishes in less time than it took to speak.
The outcome
Mouhami is in production as a commercial practice platform rather than a demo. A lawyer signs up, sets up a firm, invites members with distinct roles, and works through clients, matters, documents, hearings, time entries and invoices in one place — with dictation as the entry point to the drafting work rather than a separate toy feature. The interface is Arabic-first and right-to-left throughout, with French available where the profession uses it, and the same account works from a desktop in the office and a phone between hearings.
The engineering result we care about most is that the platform is boring in the right places. The domain is modelled explicitly, so adding a document type or a jurisdiction template is a contained change. Tenancy is structural. The mobile app and the web app are the same product rather than cousins. And speech, the part most likely to be treated as magic, is instead a measured component with known trade-offs, running on infrastructure we control rather than on a third-party endpoint whose behaviour on Algerian Arabic we cannot inspect.
For the studio it also settled a working method. The rejected first round of UI work taught us that reskinning screens one at a time produces motion without change; designing the entire journey before touching code, then holding the build to that design as a hard acceptance bar, produced an experience that lawyers recognised as a legal product rather than a generic dashboard with Arabic labels.
10
Domain modules
Firm, member, client, matter, document, template, dictation, invoice, time entry and notification are modelled as separate bounded concerns rather than shared CRUD tables.
3
Product surfaces
A web application, a native mobile app and an internal admin console all run against a single API with one tenancy and permission model.
AR · FR
Drafting languages
Arabic on both sides of the pipeline, Modern Standard in writing and Algerian dialect in speech, plus French, in a right-to-left-first interface that allows switching mid-document.
DOCX · PDF
Export formats
Both carry signature and seal placement, since a large part of the profession still edits the Word file before filing.
Honestly
Dialect is where this product is still exposed. Our transcription benchmarks were run on clean broadcast Modern Standard Arabic, which is a lower bound rather than a representative sample: Algerian darija, spoken quickly, with French clauses and proper nouns, is harder and remains the real risk in the pipeline. Because of that the self-hosted transcription tier ships gated, with the application still able to fall back, so that switching it on is a decision taken after end-to-end validation on real lawyer dictation rather than on launch day.
A second accepted cost is that speech runs on its own machine rather than beside the application, which adds a network hop to every dictation. Moving it alongside the application would remove that hop, and the provisioning was written to be repeatable precisely so the move stays cheap. We kept the current arrangement while the model choice is still settling: on a batch pipeline where a dictation already takes minutes, a few milliseconds of round trip is the smallest problem on the list, and treating it as urgent would have been optimising the wrong thing.
Frequently asked
Can AI really draft legal documents in Arabic?
It can draft the structure reliably and the language well, but it should not be trusted unreviewed. Mouhami transcribes the lawyer's own dictation and maps it into the expected shape of a petition or court memorandum, then hands the draft to an A4 editor for correction before export. The lawyer remains the author; the platform removes the typing, the boilerplate and the formatting, not the judgement.
How do you handle Algerian dialect in speech-to-text?
We run self-hosted transcription rather than a black-box API, so the model can be chosen, benchmarked and swapped against real audio. We measured candidate models for both speed and word error rate on Arabic material and selected on that evidence. Dialect remains the hardest case, which is exactly why we keep the speech tier under our own control instead of trusting a vendor's benchmark.
Is client data from different law firms kept separate?
Yes, and structurally rather than by convention. Every command and query derives the firm from the authenticated token, and the firm identifier is never accepted as an input from the client. There is no request a user can construct that names another firm's data, so cross-tenant access is not a check that could be forgotten in a new endpoint.
Does the exported document work in Microsoft Word?
Yes. Export produces both DOCX and PDF, with the signature and seal placed as a filing expects. DOCX matters in particular because much of the profession makes final edits in Word before printing or filing, so an export that only produced PDF would push work back out of the platform at the last step.