Point of sale, inventory and finance for retail shops: checkout to payroll on the hardware a shop already owns, with every amount stored exactly so the month-end numbers always match the receipts.

Nova Store runs a shop's whole day: checkout, stock, purchasing and suppliers, customer credit, shifts, expenses, payroll and reporting. It runs on hardware shops already own: a Windows PC at the till, a thermal printer, a cash drawer, and a phone camera for barcodes.

POINT OF SALE — INVENTORY — FULL-STACK

Client
TODO: client name, or "Retail shops in Iraq" if they prefer not to be named
My role
Product design and full-stack engineering, from the first schema to installs in the field.
Duration
May 2026 – present
Tools

Overview

Nova Store is a point-of-sale, inventory and finance system for retail shops. I designed and built it end to end, from the database schema to the installer that runs on a customer's computer.

It covers the full shop day: • sales and refunds • stock, purchasing and suppliers • customer and supplier debt, and prepaid customer cards • shifts, expenses and payroll • reports

Every till, printer and phone in the shop works from the same data.

Context

Several tills, the stockroom and the owner all work from the same data.

The system has to handle the full variety of a real shop: services with no stock, composite products built from ingredients, promotions, prepaid cards with balances, card terminals, kitchen tickets and end-of-shift handovers.

Problem

Small retailers run on paper ledgers, WhatsApp and memory. The till, the stock count and the month-end numbers never agree, and the owner can't see where the money went.

Two things make this hard to fix with off-the-shelf software: • It has to be trusted with money before anything else. One rounding error in a total and the owner stops believing the system. • It has to fit the shop as it is: the hardware it already owns, staff who learn on the job, and no IT department.

Constraints

No IT support. The owner installs it on the shop's own computers and updates it without a technician visit.

Cheap, varied hardware. Receipt printers, cash drawers, kitchen printers, and several tills working at once.

Arabic throughout. The interface, receipts, PDF reports, and the changelog the owner reads.

Never ship untested code. A shop must only ever run a released version.

Architecture

The front end is a React web app, installable on every till and phone, running on a Node.js API and a PostgreSQL database.

Each area of the shop has its own module with its own rules and permissions: sales, inventory, purchasing, finance, payroll, shifts and printing.

Live notifications appear on every open screen: items nearing expiry, debts coming due, and report reminders. The system also backs itself up.

Key decisions

Money is Decimal, and every sale is one transaction. Every financial field is an exact Decimal, never a floating-point number. A sale records its items, payment, stock movement and ledger entry together or not at all, so month-end totals always match the receipts. (Full write-up in the build log.)

Permissions live on the server. Each role gets exactly the actions it needs, enforced by the system itself rather than just hidden in the interface.

Printing that works on any till. Receipts and kitchen tickets print straight from the app to the shop's own printers, with no driver setup and no print dialog in the way.

Releases, not surprises. Shops install tested releases from inside the app, in one click. Each release comes with a plain-language changelog written for the owner, not for developers.

Fast at the counter. Cashiers sign in in seconds and scan barcodes with a phone camera. A sale takes as few taps as possible.

Corrections leave a trail. Stock adjustments and balance fixes require a written reason and are recorded, so it's always clear who changed what, and why.

Hard problems

Installers that broke on real PCs. The first installer failed on real customer machines because of Arabic text, unusual folder paths and missing tools. It was rewritten to work on any Windows setup, so an owner can install without help.

Receipts nobody could read. Real use showed receipts were too long and the type too small. Receipts and kitchen tickets were cut to about half their length and the font enlarged. A cash drawer that wouldn't open was fixed along the way.

The kitchen printer on the wrong machine. In practice, shops plugged the kitchen printer into the cashier's computer, not where the system expected it. Printing now drives receipt and kitchen printers from the same machine.

Security

• Permissions by role, enforced by the system for every action. • Secure sign-in, protected passwords, and validated input throughout. • An audit trail of every sensitive action, with a required reason for manual corrections.

Result

In production, delivered as tagged releases and installed in the field. It covers the shop from checkout to payroll, with every amount of money stored exactly.

TODO: how many shops run it (or "running daily at [client] since [month]"), and one concrete change, for example "month-end close no longer needs a manual recount."

Stack

Web: React · Vite · Tailwind CSS · PWA Backend: Node.js · PostgreSQL · Prisma

What I'd do differently

Design for many tills from day one. Nova Store began as a single-computer app. Moving to a setup where several tills share one source of truth later cost a migration.

Treat installers as tested software. Most early field problems were in installation, not in the application. A properly tested installer would have caught them before a customer did.

Selected projects / Keep exploring

A little more of my work.

View all work

Have a project in mind?


Get in touch