Custom ERP & Inventory Software for Trading Businesses

We build offline-first ERP and inventory software for trading businesses: tills that keep selling when the internet drops, stock figures owners can act on, and ledgers that post themselves.

Why 3 systems disagree in a trading business

By month end, the physical stock, the spreadsheet and the ledger tell three different stories. A counter sale was written in a bill book. Somebody entered it into a spreadsheet later that day, or the next day, or not at all if the counter was busy. The accounts entry happened separately, from the bill book, by a different person.

Reconciling those three versions is somebody’s whole week. The knock-on effects cost more than the admin does. Purchasing decisions are made against stock figures nobody trusts, so the safe move is to over-order, and that is how dead stock accumulates. Counter staff cannot answer a simple availability question without walking to the warehouse to look. Gross profit by product line exists only in theory: the owner knows the business is profitable, but not which lines are carrying it.

Nine years in electrical trading at Star Electric

That background changes how we scope the work. We have stood at a counter on a Saturday, watched a cashier serve three customers with two cables that look the same but carry different ratings, and seen what happens when the till and the stock sheet disagree at the end of the day. Star Electric runs retail counters and a warehouse off the same catalogue: cable by the metre, switchgear, fittings, lighting, thousands of line items. The Star Electric POS case study covers the build in detail.

What we build: 10 parts of a trading ERP

• Offline-first tills. Each counter holds a local database, keeps selling through an outage and syncs when the connection returns. The cloud is the reconciliation layer, not the dependency.
• Barcode checkout. Scanning replaces the judgement call that introduces most stock errors. Two similar cables stop being a guess at the counter.
• One write, three records. A sale posts the stock movement, the generated tax invoice and the ledger entry in a single transaction.
• Multi-branch stock. Branches and the warehouse see the same position, and transfers are sent from one site and received at the other.
• Supplier ledgers. Purchases post against the supplier account as they happen, so what you owe each vendor is live rather than a month-end exercise.
• Role permissions. Counter staff can sell and look up stock but cannot adjust stock, change prices or edit a completed invoice. Adjustments need a supervisor and leave an audit trail.
• FBR digital invoicing. Where the business falls under FBR’s rules, invoices report as they are issued and the receipt carries the invoice number and QR code.
• Payment matching. Raast, JazzCash, Easypaisa, bank transfer and cash on delivery are matched to the sale, with the unmatched ones listed for the day’s reconciliation.
• Khata and credit ledgers. Customer credit limits, balances and statements live in the system, not in a drawer, so a regular’s account is visible before the next sale.
• Reports owners use. Daily sales, margin by product and category, stock value, cash by counter and cashier, and what customers and suppliers owe. One screen, with detail a click away.

Offline-first tills, load-shedding and PostgreSQL

Load-shedding and patchy connectivity are facts of trading in Pakistan. A till that stops selling when the internet drops is worse than a bill book, so every counter keeps its own local database and keeps trading through an outage. Sales, stock movements and receipts are stored locally first, then sync to the shared PostgreSQL database when the connection is back.

The cloud database is where reconciliation and management reporting happen, not where the counter waits. That means a busy Saturday does not depend on your broadband, and a dispute about a sale can still be traced from the local record, the sync log and the audit trail.

The Electron, React and PostgreSQL stack

• Electron
• React
• TypeScript
• Node.js
• PostgreSQL
• Prisma
• Docker

Electron gives us a desktop till that installs on a counter PC and keeps a local database beside it, which is what makes offline-first practical. React and TypeScript keep the billing screen fast and predictable for staff who serve all day. On the server, Node.js, PostgreSQL and Prisma handle the shared stock, ledgers and reporting, with Docker so the deployment is repeatable rather than bespoke to one machine.

This is the stack the Star Electric system runs on, and it is the stack we quote for trading ERP work unless a client’s existing infrastructure gives us a good reason to change it.

Rollout: 4 stages from discovery to go-live

1. Discovery and counter walkthrough. We watch a normal trading day, note the workarounds, and list the reports managers actually ask for. This is where scope is agreed in writing.
2. Data model and trial import. Products, prices, barcodes, opening stock, customer balances and supplier balances are mapped and imported into a test copy. You check a sample before any real data moves.
3. Build and parallel run. The tills, stock, ledgers and reports are built and tested, then the new system runs alongside the old one for a few days so totals can be compared.
4. Go-live and training. Staff are trained at the counter, managers on the reports, and we stay close through the first weeks of trading because that is when the small questions surface.

For planning: a first scoped build covering stock and invoicing is typically four to eight weeks. A full multi-counter ERP of the Star Electric type is a larger scope, and our planning expectation for that is eight to sixteen weeks. Both figures are estimates agreed against the actual scope, not a promise made before discovery.

Pricing: from $499, quoted per scope

Payment follows the standard Devsio schedule: 40% to start, 30% at build review, 30% at launch. We invoice in USD, and can quote and invoice in GBP or EUR if that suits your books. Hardware, third-party licence fees and FBR registration costs are excluded and listed separately before you commit. The Devsio pricing page lists the other service starting points.

FBR invoicing, Raast and payment matching in Pakistan

For Pakistani clients, the practical tax question is FBR digital invoicing, and it has to work inside a busy sale rather than after it. Where a business falls under FBR’s rules, each sale can be reported as it happens and the printed receipt carries the FBR invoice number and QR code. The details that usually break, such as a failed connection mid-sale, reprints, returns and invoices that need retrying, are handled in the software so the counter keeps moving.

Payments are the other half of the reconciliation. Raast transfers, JazzCash and Easypaisa wallets, bank transfers and cash on delivery all arrive through different channels, and a sale is only settled when the money is matched to it. The ERP holds the payment record against the invoice, lists the day’s unmatched items, and matches cash handed in by a rider or a counter to the orders they cover. Without that, the cash drawer and the bank statement disagree even when every sale was entered correctly.

Khata culture matters too. Credit customers settle weekly or monthly, and the system has to show a balance and a statement the customer recognises, not a spreadsheet row that only the accountant understands.

When should you buy a boxed POS instead?

If you run one till, sell a simple catalogue at one price, take payment in full and do not need FBR reporting, a boxed POS subscription is the right buy. It will be cheaper and it will work. We say this on first calls more often than you would expect, because a custom build only makes sense when the way you trade does not match what the boxed software assumes.

The signals for custom are specific: wholesale and retail prices to the same customer, several units of measure, credit accounts, stock that moves between branches, counters that must keep selling during an outage, and ledgers that have to post themselves. When three or more of those are true, the subscription cost usually climbs and the workarounds multiply.

Proof: the Star Electric POS case study

Star Electric Enterprises is a real electrical trading business in Saddar, Rawalpindi, with retail counters, a warehouse and thousands of SKUs. The system we built for it replaced manual paper billing, introduced offline-first tills at four counters, and made the stock figure something the owner could use for purchasing rather than pad against. The case study reports four counters in real-time sync and a 0.2-second barcode scan latency, both marked illustrative. Read the Star Electric POS case study for the problem, the build and what changed.

The same team built the wider Devsio portfolio, including websites, e-commerce and mobile apps. If your bottleneck is repetitive admin rather than stock, the AI and workflow automation service is the better starting point, because a workflow can often remove the queue without a full ERP build.

6 questions about custom ERP software