Software that respects a restaurant's books
MFAHHIQ ERP 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.
Technology that helps businesses move forward
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.
People who understand the numbers behind the business
Managing Director & Co-Founder
Rajab Rasheed
He is a seasoned financial professional with over 10 years of experience in Finance, Accounting, Audit, Taxation, Business Advisory, and ERP Consultancy. He is an ICAEW Finalist, ICMA Managerial-level professional, Master's in Accounting, and CA Affiliate, and completed his CA apprenticeship with UC&CS Global.
He has extensive experience in Construction, Trading, Logistics, FMCG, and CPEC projects across Pakistan and Saudi Arabia. His ERP and accounting software expertise includes Meezan, Odoo, SMACC, Tally, Xero, SAP, Microsoft Dynamics 365, and Oracle.
With a strong combination of professional qualifications, industry experience, and ERP expertise, he helps organizations improve financial controls, reporting, business processes, and overall operational efficiency.
Finance & ERP Advisory
Ghazi Abbas Ghrmani
Ghazi Abbas Ghrmani is a Qualified Chartered Accountant (ACA) with over 14 years of diversified professional experience across finance, accounting, financial reporting, financial planning and analysis, budgeting, forecasting, cash flow management, taxation, audit, risk management, and internal controls.
Currently working as a Finance Manager in an EPC company in Saudi Arabia, he has hands-on experience in project finance, project cost monitoring, revenue recognition, financial reporting, liquidity management, regulatory compliance, and ERP implementation.
He supports senior management through timely financial analysis, budgeting, cash flow forecasting, and performance reporting. His background includes internal and external audit, control evaluation, risk management, and policy development, with a proven ability to improve financial processes, coordinate cross-functional teams, and deliver accurate results within demanding deadlines.
AI Automation Engineer & Full-Stack Developer
Abdul Rehman
He is a skilled AI Automation Engineer and Full-Stack Developer with experience in web application development, AI integration, business process automation, API development, and software engineering. He specializes in building modern, scalable, and user-focused digital solutions by combining Full-Stack Development, Artificial Intelligence, and workflow automation.
He has hands-on expertise across modern technologies including React, Next.js, JavaScript/TypeScript, Node.js, Express.js, NestJS, MongoDB, PostgreSQL, REST APIs, Python, n8n, Git, and GitHub. His AI and automation experience includes LLM integration, AI-powered features, intelligent workflows, API automation, data processing, AI agents, and automation of repetitive business processes.
With a strong combination of software engineering, AI, and automation expertise, he helps organizations transform ideas and manual processes into efficient, intelligent, and scalable digital solutions. He focuses on improving operational efficiency, reducing repetitive work, enhancing user experience, automating workflows, and continuously improving products through technology and AI.
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/MFAHHIQ 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: falseon 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.