Software that respects a restaurant's books
Meezan ERP POS is a desktop application, not a subscription to someone else's server. This page is about how it is built and the decisions we refused to compromise on — because in accounting software, what a product declines to do matters as much as what it does.
Our vision and mission
Our Vision
To become a trusted technology partner for businesses worldwide by delivering innovative, secure, and intelligent digital solutions that simplify business operations and drive sustainable growth.
Our Mission
MFAHHIQ is committed to empowering businesses with reliable and affordable technology solutions, including professional web development, customized business email, accounting software, and tailored IT services. We aim to simplify complex business processes, improve efficiency, and help organizations operate smarter through modern, user-friendly, and scalable technology.
Our Core Promise
Simplify. Connect. Grow.
At MFAHHIQ, we believe technology should make business easier — not more complicated. We combine innovation, practicality, and customer-focused service to create solutions that help businesses work efficiently, stay connected, and grow with confidence.
Most restaurant software assumes things that are not true
It assumes the internet is always up. It assumes you will not mind a fee on every transaction you ring through. It assumes your ledger, your recipes and your customer list can live on a server you do not own, in a format you cannot read, under terms that can change.
None of those assumptions survive contact with a real dining room. The line goes down in the middle of service and the till stops taking orders. A percentage of every ticket compounds quietly into one of your larger costs. And the day you want to leave, you discover that leaving means exporting a spreadsheet and starting again.
Meezan ERP POS is built on the opposite assumptions. It is a desktop application that runs entirely on your machine, keeps its database in a file you can copy, charges once for the licence rather than per transaction, and makes no network calls at all. It owns nothing of yours.
What that means in practice
- The internet is optional, permanently. There is no server component at all, and the database is one JSON file on disk. Unplug the router and nothing changes.
- No per-transaction cut. The licence is one-time and node-locked to the machine. Ringing more covers costs nothing extra.
- Your data leaves whenever you like. It is mirrored to plain, readable files in your Documents folder that survive an uninstall.
- Nothing is reported anywhere. There is no telemetry, no analytics and no licence check-in, because there is no network code to carry them.
One plain file, hardened rather than rebuilt
The application is a single renderer file of around 34,500 lines holding the whole interface — every screen, every report — as pre-compiled React.createElement calls in one <script> tag. There is no bundler, no separate frontend build, no backend to stand up alongside it.
Why so plain, on purpose
A restaurant does not need a distributed system to run its books. One file, wrapped in Electron with a narrow, explicitly-listed bridge to the filesystem, has fewer places for something to go quietly wrong than a stack of services talking to each other — and it is the whole reason the application can run with the internet unplugged, permanently.
What went into hardening it
The desktop shell around that file has had real, adversarial attention: a Content-Security-Policy on every response, contextIsolation and sandbox switched on, navigation and window-open guards, every file operation confined to the app's own user-data directory rather than left open to an arbitrary path, and atomic, fsync'd writes with a rolling backup so a crash mid-save cannot corrupt the primary database.
An adversarial code review found eight real issues along the way — among them, silent save failures that could lose data with no warning, and a backup-rotation bug that could let a corrupt primary overwrite the one good copy — and all eight were fixed and re-tested before release. That is the standard of scrutiny this file gets, not a rewrite for its own sake.
| Layer | Shape |
|---|---|
| Renderer | 1 file, ~34,500 lines |
| Backend | none — an in-process IPC bridge, not a server |
| Data | 1 JSON document, atomic writes, rolling backup |
| Screens | 47 in the sidebar (Restaurant setup) |
| Auth | password-checked account switching, 3 role labels |
| Tests | 49 automated, across 3 suites |
What we refused to do
Every one of these made the product harder to sell in the short term. Each of them is in the code, and each is the reason to trust the rest of it.
We do not fabricate a ZATCA signature
The module generates UBL 2.1 XML, the invoice counter value, the PIH hash chain with integrity verified on every read, and the Base64 TLV QR payload for tags 1 to 5. Tags 6 to 9 carry the digital signature and signing certificate, and those need a CSID that only ZATCA issues during device onboarding. Until yours is loaded, documents stay flagged signed: false rather than emitting a QR code that looks compliant and is not.
We do not let a posted entry be edited in place
Once a journal entry is posted it is history. A correction posts a reversal, and the original stays visible and auditable next to it. Version 1 allowed the edit; that is precisely the kind of convenience that makes a ledger impossible to defend when someone asks what changed and when.
We do not accept an entry that does not balance
Unbalanced journal entries are rejected, and so are postings to accounts that do not exist. Version 1 accepted both silently, which meant the damage surfaced weeks later in a report nobody could reconcile. Stock consumption is transactional too — a failed consumption leaves nothing half-mutated.
We do not hold your data
The live database sits in your own user-data folder and is mirrored on a throttle to Documents/Meezan ERP Restaurant/ as plain, human-readable files that survive an uninstall. Writes are atomic and fsync'd with a rolling backup, and a corrupt primary falls back to the backup automatically. Copy the folder to another machine whenever you want.
We do not phone home
There are no network calls anywhere in the application. No telemetry, no crash reporting, no licence server, no update ping. The renderer has no filesystem surface at all — every file operation goes through the local API or a native save dialog — and every permission request the browser engine can make is denied.
We do not charge per transaction
A one-time licence per machine, with a year of updates and support included. Your busiest night of the year costs the same as your quietest. Nothing about the pricing model gives us a reason to want visibility into your revenue, which is a large part of why we have none.
The engineering standard we hold ourselves to
These are counts from the shipped build, not aspirations. They exist for one person: whoever is closing the till at eleven at night with a queue still at the door.
Each of those numbers is a promise to that person. Checked before it posts means a mistyped quantity is refused at the door rather than turning into NaN three screens later. One JSON document, atomically written means a crash mid-save cannot leave the database half-written — the primary is only ever replaced once the new copy is safely on disk.
47 screens in one file means the whole application, not a slice of it, loads once and stays fast on the modest hardware restaurants actually buy. 49 automated tests run before anything ships, checking real accounting behaviour — costing, cost centres, combined statements, approvals — against worked examples, not just that the screens render.
Zero network calls means the worst thing the internet can do to your service is nothing at all. Add to that contextIsolation: true, nodeIntegration: false, sandbox: true, a Content-Security-Policy on every response, navigation guards, and no server component for anything to listen on — and there is simply nothing on the network to attack.
Built for Saudi Arabia
Not localised after the fact. The tax behaviour, the invoice artifacts and the module structure were designed around how businesses here actually operate.
VAT that is extracted, not added
Menu prices in a restaurant are what the guest pays. POS pricing is therefore VAT-inclusive throughout: on a gross ticket of 46.00 at 15%, the net is 40.00 and the VAT is extracted from the price rather than bolted on top of it. Getting this backwards is the single most common source of a ledger that disagrees with the till roll.
ZATCA Phase 2 artifacts, prepared properly
UBL 2.1 XML, the invoice counter value, and a PIH hash chain whose integrity is verified on every read — not only on write. The QR payload carries tags 1 to 5 in Base64 TLV: seller name, VAT number, timestamp, invoice total and VAT total. Everything is ready for the moment your CSID arrives.
Riyals, and the reports that follow them
Amounts are formatted in Saudi riyals throughout, from the POS ticket to the trial balance. Both FIFO and weighted-average costing are supported and chosen in Settings, fixed assets depreciate straight-line with the same period refused twice, and contracting projects recognise revenue on IFRS 15 percentage of completion.
Seven business natures, one application
The sidebar adapts to what you actually do. A restaurant sees inventory, POS and tables, with manufacturing off unless a commissary kitchen needs it; trading sees inventory and POS without the floor plan; contracting swaps all of it for projects and approvals; a services business sees none of the stock modules at all. The full mapping across restaurant, trading, trading and manufacturing, trading and services, manufacturing, contracting and services is set out on the features page.
Where it is going
We would rather describe directions than dates. These are the areas we expect to spend time on next, written plainly so you can judge whether they matter to you.
What we expect to work on next
Deeper ZATCA once a CSID is loaded
The artifacts are already prepared. The direction is to complete the signing path end to end for businesses that have finished device onboarding, so tags 6 to 9 are populated from a real credential and documents move past signed: false on their own.
More report formats
The reports are there — profit and loss, balances, inventory valuation, aged receivables and payables, customer and vendor statements. The work ahead is in how they leave the application: more export formats, and layouts that suit an accountant receiving them rather than only a screen displaying them.
More languages
The interface is English today. Extending it is a direction we take seriously given where the product is used, and we would rather ship it properly than announce it early. If this decides your purchase, ask us where it stands before you buy.
Whatever restaurants keep asking for
The most reliable input we have is the same question arriving three times in a month. Support and the roadmap are the same inbox, which is deliberate.
See whether it holds up
Principles are cheap to write down. Put your own menu on the till, ring a ticket through, and check the ledger afterwards.