Al-Makhzen (المخزن)
Smart restaurant cost management solution for Tunisia. Features AI-powered invoice scanning, automated recipe costing, real-time profitability analytics, and inventory tracking to help restaurant owners maximize profits.
Overview
Al-Makhzen is a specialized ERP solution built for the Tunisian restaurant industry. It tackles the critical challenge of food cost control by digitizing the entire inventory workflow. Users can snap photos of supplier invoices, which are processed via OCR to update stock levels and prices automatically. The system then calculates real-time recipe costs (Fiches Techniques) and compares them with sales data to analyze profitability per dish. It supports multi-branch management and provides actionable insights to reduce waste and theft.
Key Features
- AI Invoice OCR: Instantly digitize paper invoices with high accuracy.
- Recipe Costing: Real-time calculation of food costs based on ingredient prices.
- Inventory Management: Supplier tracking, stock alerts, and waste logging.
- Profitability Analytics: Dashboard showing margins per dish and daily P&L.
How it was built
The problem
Food cost is the number that decides whether a restaurant survives, and in most independent kitchens it is tracked on paper or not at all. Deliveries arrive with a supplier slip that someone intends to key into a spreadsheet later and usually does not. Ingredient prices move week to week, so a fiche technique costed in the spring is quietly wrong by the summer — and because the dish price on the menu did not move, nobody notices the margin eroding until the end of the year. Ask an owner which of their dishes actually makes money and the honest answer is a guess.
The tooling that solves this elsewhere does not fit this market: it is built for chains with a back office, priced accordingly, and offered in French or English. The person who actually receives the delivery is standing in a kitchen doorway with a phone, works in Arabic, and has very little attention to spare. Al-Makhzen was built for that person — the capture surface has to be the phone already in their hand, the interface has to be in their language, and entry has to take less effort than the paper process it replaces, or it will not be used.
Approach & architecture
The product is a React Native app because the moment that matters — a delivery arriving — happens away from a desk, and the camera is the input device. The invoice pipeline is deliberately staged: capture, image preprocessing, OCR and vision extraction, structured parsing into candidate line items, a human confirmation screen, and only then a commit to the database. The load-bearing decision is that OCR output is a proposal, never a write. A model that silently mis-reads a price corrupts every recipe that uses that ingredient and every margin report downstream, so the system is designed to be fast to confirm rather than fully automatic — the reviewer taps through pre-filled lines instead of typing them, and low-confidence fields are visually flagged so attention goes where it is actually needed.
Beneath that, the data model is built around time. Ingredient prices are stored as an append-only series of purchase observations — supplier, unit, price, date, source document — rather than as a mutable current_price column. Recipe cost is then a pure function of a recipe and a date, which is what makes historical profitability meaningful instead of a retroactive fiction. Recipes are trees, not flat lists: a pizza references a dough and a sauce, each of which is itself a costed sub-recipe with its own yield, so costing is a recursive walk that resolves sub-recipes, applies unit conversions and accounts for preparation loss before rolling up.
Supabase Postgres holds the ledger, with row-level security scoping every query to a branch so multi-site owners get consolidated reporting without any cross-tenant read being possible. The original invoice photograph is kept in object storage and linked to the rows it produced, which turns the audit trail into something a human can settle an argument with: every stock movement and every price can be traced back to a picture of the paper it came from.
Engineering challenges
OCR on receipts that were never designed to be read by a machine
Real supplier documents are creased thermal paper photographed at an angle under kitchen lighting, with handwritten quantities in the margin and a layout unique to each supplier. Raw text extraction is only the first step; the harder part is turning a soup of strings into line items. The app preprocesses images for deskewing and contrast before extraction, then applies per-supplier layout memory so a vendor whose documents have been seen before is parsed with far more structure than an unknown one. Free-text product names are fuzzy-matched against the ingredient catalogue with an alias table that learns from each correction, so the second delivery from a supplier needs much less intervention than the first. Anything below a confidence threshold is escalated to the reviewer rather than guessed at.
Arabic RTL in React Native is not a stylesheet flag
Right-to-left support in React Native runs through I18nManager, which flips layout at the native level and needs an application reload to take effect — so direction is resolved at boot rather than toggled mid-session, and the app has to restart itself gracefully. Layouts are written with logical start and end properties instead of left and right, because hardcoded directions stay invisible until the mirror is switched on. Directional iconography — back arrows, chevrons, swipe affordances — must mirror, while numerals, currency amounts and dates must not, so the flip is selective rather than global. Mixed-direction text is the persistent trap: a Latin-script supplier name inside an Arabic sentence is resolved by the bidirectional algorithm in ways that surprise you, especially around punctuation and trailing digits, so strings that embed data need explicit isolation. Fonts are chosen for correct Arabic shaping rather than for their Latin character set, and every screen is tested in both directions, because a layout that is fine in one can be unusable in the other.
Units, yields and the difference between bought and used
Suppliers sell in crates, cartons and kilograms; recipes consume in grams, millilitres and pieces. Costing a dish correctly means a conversion graph per ingredient — and per supplier, since the same product arrives in different pack sizes from different vendors — plus a yield factor for preparation loss, because a kilogram of purchased vegetables is not a kilogram of usable product after trimming. Costing on as-purchased price instead of as-used cost systematically understates food cost, which is precisely the error the product exists to eliminate, so conversions and yields are first-class fields rather than something the user must pre-compute.
History that does not rewrite itself
If editing a recipe or receiving a new delivery changed past reports, the analytics would be worthless. Recipes are versioned and price observations are append-only, so a margin calculated for last month is computed against the recipe version and the prices that were actually in effect then. Stock movements are recorded as an immutable ledger of receipts, consumption and waste, with current stock derived from that ledger rather than stored as a mutable number — which means a discrepancy can be investigated by reading the history instead of being silently overwritten by a correction.
Stack decisions
- Mobile clientReact Native
- The critical workflow is camera-first and happens on the floor, not at a desk. One codebase covers both mobile platforms while still giving native camera and storage access, and it exposes the native RTL layout machinery the Arabic interface depends on.
- Invoice captureComputer vision / OCR APIs behind a confirmation step
- Managed vision services handle mixed-script text on poor-quality photographs far better than anything worth building in-house, but they are treated as a suggestion engine. Parsing, matching and human confirmation are application logic, which keeps accuracy under the product's control rather than the vendor's.
- DatabaseSupabase Postgres with row-level security
- Costing is recursive and relational — recipes into sub-recipes into priced ingredients — which is exactly what SQL is good at. RLS enforces branch isolation at the data layer so multi-site reporting cannot leak between locations.
- Document storageObject storage linked to the rows it produced
- Keeping the original photograph beside the extracted data makes every price and stock movement auditable back to source, which is what lets an owner resolve a dispute with a supplier instead of taking the software's word for it.
- LocalizationArabic-first interface with full RTL layout
- The staff doing receiving work in Arabic are the primary users, so Arabic is the design default rather than a translation applied afterwards — which is the only way the mirrored layout, typography and number handling end up coherent.