Custom POS and inventory systems built for multi-branch retail

The short answer

POS system development means building point of sale and inventory software around how your business trades, instead of reshaping your process to fit a subscription product. A sound build gives every branch tills that keep selling when the connection drops and sync when it returns, barcode scanning including weighed items, stock rules per location, supplier purchasing, returns against the original receipt, and cash that balances at shift close. Good inventory management system development records every stock movement (sale, return, receipt, transfer or adjustment) and calculates stock on hand from those movements, so any figure on screen can be traced back to the transactions behind it.

Growth Informer Software Services builds these systems from Kampala, Uganda, for retailers and software companies worldwide, and runs Growth Informer Business, our own live cloud POS, inventory and business platform. A custom POS and inventory build is typically , fixed in a quote before work starts, paid on a 50/25/25 plan, and you own the source code and data. If you run one or two shops with standard stock, a subscription POS or a licensed script such as UltimatePOS may be enough, and we can install and customise a script instead of building from scratch.

What a custom POS and inventory system should handle

Most retail losses happen in the gaps between the till, the stockroom and the supplier. These are the modules we scope for a serious build, and you choose how deep each one goes.

Tills and checkout

• Offline-first selling: each till holds its catalogue, prices and open shift locally, so a dropped connection does not stop a sale.
• Barcodes: scan manufacturer barcodes, print shelf and product labels, and read weighed items labelled with GS1 restricted circulation numbers (prefixes 20 to 29), where the price or weight sits inside the barcode in a layout that varies by market.
• Split tender: cash, card, mobile money, store credit and vouchers on one receipt.
• Shift control: opening float, cash drops, blind cash counts and an end of shift report showing variances by cashier.

Stock rules

• Reorder points per branch with minimum and maximum levels, and suggested orders built from real sales velocity.
• Batch, expiry and serial tracking where you need it, with first expiry, first out selection at the till.
• Units of measure: buy by the case, sell by the unit, and keep the conversion exact.
• Transfers between branches with an in-transit state, so stock is never counted twice or lost on the road.
• Stock takes and adjustments with reason codes and manager approval above a threshold you set.

Suppliers and purchasing

Purchase orders, goods received notes that accept partial deliveries, supplier price lists and landed cost, so margin reports include freight and duty. Supplier returns and credit notes close the loop.

Returns and refunds

Returns are looked up against the original receipt, refunded to the original payment method by default, and routed either back to sellable stock or to a damaged location. A refund without a receipt, or above a limit, needs a manager override that is logged against a named user.

Reporting

Sales by branch, cashier, hour and category, gross margin, slow and dead stock, and shrinkage by reason. Owners see every branch in one view, and branch managers see only their own.

Multi-branch and offline-first: how the sync works

The hardest part of retail POS development is not the checkout screen. It is keeping many tills and branches consistent when connections are unreliable, and that has to be designed in the first sprint, not bolted on after launch.

• Stock as a ledger: every change is stored as a movement, and stock on hand is calculated from the movements rather than overwritten, so a wrong figure can be traced to the exact sale, receipt or transfer that caused it.
• No duplicate sales: tills queue transactions locally with unique identifiers, and the server accepts each one exactly once, so a retry after a network drop cannot post a sale twice.
• Receipt numbering per till: each till draws from its own number series, so two offline tills never issue the same receipt number.
• Central price control: prices, promotions and product changes are published centrally and pulled down by each till, with a version marker that shows which branch is running old prices.
• Sensible conflicts: when an offline sale takes stock below zero, the system records it and flags it for review instead of blocking the customer at the counter.

This is the same discipline behind Moyo Pay, our own dual-currency wallet built on a double-entry ledger with Mobile Money and USSD: money and stock both have to reconcile to the last unit.

Fiscal and e-invoicing integration

A growing number of tax authorities want each sale or invoice reported electronically. Kenya's KRA requires businesses to issue electronic tax invoices through eTIMS, and Uganda's URA runs EFRIS, which accepts system to system connections from a business's own invoicing software. Offline-first tills make this harder than it looks: a sale made during an outage still has to reach the tax authority, so the queue, the retry rules and what prints on the receipt must follow the authority's specification. We scope each country separately, build to the published specification and test against the authority's test environment where one exists. Meeting the fiscal rules remains your obligation as the retailer, and we confirm feasibility before we quote. Trading in Uganda? Our POS and inventory system for Uganda page covers the local picture.

UltimatePOS, a subscription or custom POS software: which fits

Plenty of retailers start with a script. UltimatePOS, a Laravel POS and stock management script sold on CodeCanyon, has close to 7,000 sales, which shows how many businesses would rather host and control their POS than rent it. There are three honest routes, and custom POS software development is only one of them.

A subscription POS

Right for one or two shops with standard products, no integrations and a need to trade next week. Revisit it when per-till or per-branch fees climb with every location you open.

A licensed script such as UltimatePOS

A one-off licence, hosted on your own server, with optional add-on modules from the vendor. Someone still has to install it, secure the server, apply updates and customise it. Heavy customisation carries a cost you pay later: every vendor release has to be merged with your changes, and the core code stays under the vendor's licence rather than becoming yours. We install and customise scripts when that is the cheaper, sensible call.

A custom build

• You run several branches or a warehouse and need transfers with an in-transit state.
• Your stock rules, such as batches, expiry, units of measure or approval limits, fight the product's data model.
• Tills must keep selling through internet outages, not just show an error.
• The POS has to connect to your ecommerce store, accounting, loyalty scheme or a fiscal system the product does not support in your market.
• You are a software or fintech company building a merchant POS as a product, and you need to own the code, the data and the roadmap.

Whichever route you test, run three checks before you commit: unplug the router at a till and complete a sale and a refund; transfer stock between two branches and see where it sits while on the road; and receive a partial supplier delivery against a purchase order. Hospitality is a different build, with table plans, modifiers and kitchen tickets, covered under restaurant management system development.

What retail POS development costs

Every project gets a fixed quote after scoping, so the figures below are indicative ranges for your region, not a rate card. Pick the row closest to your situation.

Four things move a custom POS quote most. Offline sync, because conflict rules and queued fiscal records need design and testing, not just a local cache. Each outside integration: a card terminal, mobile money, accounting, ecommerce or a fiscal system. Stock depth, since batches, expiry, serial numbers and units of measure touch almost every screen. And branch count, which adds transfers, per-branch pricing and permissions. Phasing keeps the first payment down: a pilot branch can run on the core till and stock while the rest is built.

Payment follows our 50/25/25 plan, and the price is fixed before any work starts. A full card or payment gateway build is usually scoped on its own: see payment gateway integration services. At the till, we prefer card terminals that encrypt the card inside the device so card numbers never reach your database, and a validated point-to-point encryption solution can reduce the scope of your PCI DSS assessment. If the POS is one part of a larger system, see ERP software development.

Why build your POS with us

A POS is not a one-off website. When tills stop syncing on a busy Saturday, you need the people who wrote the sync logic to answer, which is where a marketplace freelancer tends to fall short. Here is what we can show rather than promise.

• A POS we operate ourselves: Growth Informer Business is our own live cloud POS, inventory and business platform, so we design tills, stock and reports from a product we run, not from a demo.
• 37 live builds: websites and apps you can open and check in our portfolio.
• A fixed quote: agreed before work starts and paid on a 50/25/25 plan.
• You own it: the source code and your data are yours, so you can host it anywhere or hand it to your own team.
• Overlapping hours: Kampala runs on East Africa Time (UTC+3), which overlaps the UK and European working day.

How a build runs

We start with your branches, product list, stock rules and payment methods, then issue a fixed quote. Delivery is staged so you see a working till early, then a pilot in one branch with real stock and real cashiers before rollout to the rest. The pilot is where offline behaviour, receipt numbering and shift variances are tested against how your staff actually work.

If a subscription renewal, a new branch opening or a fiscal deadline is coming up, ask for the quote now. Scoping shows whether a script, a subscription or a custom build is the cheaper route before you commit to another year of fees.

Frequently asked questions

How much does custom POS system development cost?

A custom POS and inventory system is typically , depending on your branches and tills, stock rules, offline sync and integrations. Installing a licensed script such as UltimatePOS is typically . Every project gets a fixed quote before work starts, paid on a 50/25/25 plan.

Will the tills keep working if the internet goes down?

Yes, with an offline-first design. Each till stores its catalogue, prices and sales locally, keeps trading, and syncs queued transactions to the server when the connection returns, with unique transaction identifiers so no sale is posted twice.

Can you customise UltimatePOS instead of building from scratch?

Yes. We install and customise licensed POS scripts, and changes such as reports, receipt layouts or an extra payment method are typically . If the changes reach the core of stock or sync, a custom build is usually the better investment, because the script code stays under the vendor's licence and every update has to be merged with your changes.

Can the POS connect to EFRIS, eTIMS or another fiscal system?

Usually. Uganda's EFRIS accepts system to system connections and Kenya's KRA requires electronic tax invoices through eTIMS, but each authority publishes its own specification, so we scope each market separately and confirm feasibility before quoting. Meeting the fiscal rules remains the retailer's obligation.

Do we own the source code and data?

Yes, for a custom build you own the source code and your data. We can host and support the system on a monthly retainer, or hand it over to your own team.