I build back ends for systems where being approximately right is the same as being wrong. Most of my work is business software — accounting, inventory, purchasing, point of sale — and in that world a rounding error is not a bug report, it is a number somebody has to explain to an auditor. That constraint is what I find interesting about it.
Panvex is the company I founded to build and run these products rather than hand them over and leave. There are ten of them now, from an ERP that carries a double-entry accounting engine to a PDF toolset that is really a job-queue problem in disguise. Running what I build is the part that has taught me the most: a design decision you have to live with for two years teaches you something a design decision you ship and forget never will.
The pattern in all of it is the same. Get the model right first — what the records are, what must never disagree with what, and where the truth lives — and the features become straightforward. Get it wrong and no amount of code afterwards recovers it. Most of the time I spend on a system is spent before there is anything to look at, and that is deliberate.
What I am looking for next is more of the hard half. A system whose rules are complicated enough that getting the model wrong is expensive: business software that has outgrown the spreadsheet it started as, an accounting or stock engine producing numbers nobody trusts any more, or a codebase somebody else left behind that you now have to live with. If that describes something on your desk, the messy version of the question is the one worth sending.
What I actually do.
Six things, described specifically enough that you can tell whether they are the ones you need. A list of technologies would not tell you that.
Data models that hold up
The schema is the system. I spend the first part of any project deciding what the records are, which of them must never disagree, and what a correction looks like — because that is the part you cannot refactor your way out of later.
Accounting and inventory engines
Double-entry journals, cost of goods, batch allocation by FIFO, LIFO or expiry, landed cost distribution, three-way matching. Money in decimals, never floats, and a document that posts to three places posts to all three or to none.
APIs meant to be integrated with
Predictable resources, validation at the edge, errors that say what to do about them, and idempotency where a client will retry. An endpoint that behaves differently on the second identical call is a bug waiting for a bad connection.
Authorisation that survives contact with users
Multi-tenant isolation, permissions per action rather than per role, elevation for the manager standing at the counter, and an audit trail written as things happen. Most breaches of a business system are ordinary users doing ordinary things they should not be able to.
Queues, workers and long jobs
Separating what is fast from what is slow, hard timeouts on anything spawning an external process, retry once rather than forever, and progress a user can actually watch. Work that takes seconds does not belong inside a request.
Arabic and English, built in
Right-to-left as a structural property rather than a stylesheet of overrides, and both languages rendered as separate pages. Retrofitting RTL onto a finished interface costs several times what building it in does.
Selected work
11 systems, all of them mine to run.
Not client case studies. These are the products this company builds and operates — open any of them and read the page it earned. Each card carries the stack it is actually built on.
SkyFinance
In development2025 — now
ERP: sales, purchasing, stock, production, POS, payroll and accounting in one tenant.
My partArchitecture and backend — data model, accounting engine, API
Built with
Node.js
Express
MongoDB
Mongoose
Decimal.js
React
What is inside
The decision that shaped everything else was refusing to let any module keep its own copy of a number. A counter sale, an office invoice and a production issue all run through the same line-item maths, the same cost-of-goods calculation and the same double-entry journal engine — so the modules cannot disagree, because there is only one of each calculation. Money is handled in decimals rather than floats throughout, and a document that posts stock, cost and a journal entry commits all three in one transaction or none of them.
Tax-ready invoicing with PDF, a verification QR code and a REST API.
My partArchitecture and backend
Built with
Node.js
Express
MongoDB
React
Tailwind
What is inside
Invoicing is deceptively hard because the document is a legal artefact, not a screen: once issued it cannot change, so corrections are new documents that reference the old one. The verification code on each invoice is what lets a recipient confirm it against the issuer rather than trusting the paper.
Retail point of sale with the supplier buying and the stock behind it.
My partArchitecture and backend — POS, purchasing, inventory
Built with
Node.js
Express
MongoDB
Transactions
React
JWT
What is inside
Built on the same engine as SkyFinance, aimed at a shop rather than an enterprise. The interesting constraints are all about trust at the counter: the terminal is never allowed to send a price, a sale cannot exist outside an open shift, a retried sale returns the invoice it already made instead of charging twice, and a refund needs an authority a cashier does not have — which a manager can supply at the till without logging them out.
Dynamic QR codes you can re-point after printing, with scan analytics.
My partArchitecture and backend
Built with
Node.js
Express
MongoDB
React
Tailwind
What is inside
The whole product is one indirection: the printed code points at a record you own, not at a destination, so the destination can change after ten thousand posters are already on walls. That makes redirect latency and uptime the product — a scan that hesitates is a scan the customer abandons.
Browser PDF toolset — merge, split, organise, compress, convert, protect.
My partArchitecture and backend — queue design, tool contract, security
Built with
NestJS
BullMQ
Redis
MongoDB
S3
Astro
What is inside
A job queue problem wearing a PDF costume. Work runs in separate light and heavy lanes so a two-page merge never waits behind a forty-second Office conversion, files go straight from the browser to object storage so the API never handles the bytes, and every uploaded and generated file is deleted two hours later by a sweeper with a storage lifecycle rule behind it. Every tool implements one shared interface, so adding the seventh is a file rather than a refactor.
Project and task management with time logging, billed per seat.
My partArchitecture and backend
Built with
Node.js
Express
MongoDB
React
Tailwind
What is inside
Task tools are easy to build and hard to make anyone keep using. The part worth engineering is the time log: it has to be quick enough to be honest, and structured enough to bill from, and those two pull in opposite directions.
Hotel management: front desk, channel sync, housekeeping and folio.
My partArchitecture and backend
Built with
Node.js
Express
MongoDB
React
Tailwind
What is inside
A hotel sells the same room to one guest a night, which makes availability a booking problem rather than a stock problem — two channels selling the last room at the same moment is the failure mode the whole design is arranged around.
Clinic management: scheduling, patient records, prescribing and billing.
My partArchitecture and backend
Built with
Node.js
Express
MongoDB
React
Tailwind
What is inside
Clinical records are the strictest data you can hold: correction has to be visible rather than silent, access has to be provable, and a schedule has to survive being changed by three people at once.
School management: students, guardians, attendance and assessment.
My partArchitecture and backend
Built with
Node.js
Express
MongoDB
React
Tailwind
What is inside
The hard part is not the data, it is the calendar — terms, timetables, holidays and cohorts all move independently, and every report a school actually wants is a question asked across all four at once.
A marketplace where university students tutor each other.
My partArchitecture and backend
Built with
Node.js
Express
MongoDB
React
Tailwind
What is inside
A two-sided marketplace has a cold-start problem before it has an engineering problem: matching, scheduling and payment are straightforward next to persuading the first hundred tutors to be there before the first hundred students arrive.
The company: the domain, the shared identity and the sites for every product.
My partDesign system, build and deployment
Built with
Astro
TypeScript
Tailwind
Sharp
Static
What is inside
Eleven static sites on one domain, sharing a design system, twelve palettes and two languages rendered as separate pages rather than switched at runtime. Products sit on sub-paths instead of sub-domains so they inherit the domain's authority, and the whole set ships about three kilobytes of JavaScript on a full page.
Four commitments rather than four adjectives. Each one is something you can hold me to, and notice if I break.
The model before the screens
I will not start building features until we agree on what the records are and what must never contradict what. It looks slower for a week and it is the only reason month six is not a rewrite.
Correct beats impressive
Where a system handles money or stock, I will choose the boring implementation that is provably right over the clever one that is probably right. I would rather tell you a feature will take longer than tell you later why a total is wrong.
You own it from the first commit
The repository, the database and the deployment are yours throughout, not at the end. Nothing I build should require me to keep it running, and I will document the parts that would otherwise only exist in my head.
You hear about the problem early
When an estimate slips or a decision turns out badly, you get told while there is still a choice to make about it. A surprise on the delivery date is a failure of communication that started weeks earlier.
The tools I reach for.
Chosen because I have run systems on them long enough to know how they fail, which is a different qualification from having used them.
Backend
Node.js
Express
NestJS
TypeScript
REST
JWT
Data
MongoDB
Mongoose
Redis
Transactions
Aggregation
Indexing
Infrastructure
BullMQ
S3 / MinIO
Docker
Cron workers
Rate limiting
Frontend
React
Astro
Tailwind
Vite
RTL / i18n
Questions
What people ask before writing.
About me and how I work. The commercial questions — price, contracts, ownership, what happens after launch — are answered on the company page instead.
What kind of work do you take on?
Back-end and architecture on systems with real rules underneath them — accounting, stock, invoicing, point of sale, scheduling, anything where the data model is the hard part and a wrong number has consequences. I am least useful on work that is mostly interface, and I will say so rather than take it.
Are these eleven systems live, or is this a portfolio of prototypes?
Each card says which it is, and most of them say "in development". This site and the product sites are live; the products behind them are being built and run by the company rather than shipped once and abandoned. I would rather show you a status you can check than a claim you cannot.
Why is nearly everything Node, Express and MongoDB?
Because I have run systems on that stack long enough to know how it fails, which is a different qualification from having used it. Toolicon is NestJS, BullMQ and Redis for the same reason — a queue problem needs a queue framework. The stack follows the problem; it is just that most of my problems have been the same shape so far.
Do you write the front end too, or only the API?
Both, but they are not equal. The React and Astro work on these products is mine, and this site is mine down to the CSS. My depth is on the server side: the model, the engine and the API contract. If a project needs a designer, it needs a designer, and hiring one is cheaper than asking me to be one.
Can I see the source?
Not publicly — these are the company's products, and several of them hold customer data. I will walk through the parts that matter on a call: the accounting engine, the transaction boundaries, the permission model. Reading code together is a better test of an engineer than a repository you skim anyway.
How do you keep eleven systems running at once?
By making them share as much as possible. EaglePOS is built on SkyFinance's engine rather than on its own; every site on this domain shares one design system, one palette file and one i18n layer; each of the eleven sites ships as static HTML, so there is nothing to keep alive. The work that scales badly is the work that gets duplicated.
What do the first two weeks of a project look like?
Almost no code. I sit with the people who will use the system, write down what the records are and what must never contradict what, and get that agreed in writing. What you have at the end of it is a model and a scope you approved — which is what makes every estimate after it worth anything.
What do you not do?
Native mobile, machine learning, design systems for someone else's brand, and anything where I would be the fourth engineer on a codebase I have no say over. I also turn down work where the deadline is fixed before the requirements are — not out of principle, but because I would miss it.
Do you work in Arabic as well as English?
Both, and the software does too. Every product here is bilingual from the schema up: right-to-left is a structural property of the layout rather than a stylesheet of overrides, and the two languages are rendered as separate pages rather than switched at runtime. Retrofitting that onto a finished interface costs several times what building it in does.
Where are you, and how do you work with people elsewhere?
[CITY, COUNTRY], working [remotely / hybrid — say which]. In practice: written updates you can read at your own hour, a call when a decision needs one, and no expectation that anybody sits in a meeting to hear something that fits in a paragraph.
Something you built went wrong. What happened?
[Answer this one honestly and specifically — the decision, what it cost, what you changed afterwards. It is the single most persuasive answer on the page, and the only one a reader cannot get anywhere else. Leave it blank rather than write a humblebrag.]
How do I start a conversation that is worth your time?
Send the problem, not the specification. What the business does, which part of it currently hurts, and what you have already tried — three paragraphs is plenty. I read everything and reply to anything with a real problem in it, and if I am the wrong person I will say so in the first reply rather than the third.
Write to me directly.
Not a form that reaches a queue. If you are weighing a system up — new, inherited or half-built — send the messy version of the question.
