Skip to content

A till and accounts for shops

Trust POS: One Core, Many Shops

A till and a set of books in one app. Every shop starts with the same core, then we switch on the extras your trade needs. It runs in ten languages, Arabic and Urdu included, and can live on your own computers.

Sale #1042Paid

Your plan this month

Basic plan — a little over half used.

Switched on for this shop

Optician: prescriptions and lenses

Sphere, cylinder, axis and add show up only for the shops that need them. Every other counter never sees them.

Languages
10
Plans
4
Platform
Works in any browser — computer, tablet or phone
Audience
Independent shops and small chains still juggling paper, or two systems that disagree
Scope
Selling, stock, customers, staff, and a full set of books
Positioning
One system that suits many trades, not a tool built for only one

Product Features

A till that keeps the books as well

Most shops end up with a till that sells and a ledger that never quite agrees with it. Trust POS records the sale and the accounting entry as one act, then reports on both.

One core, many trades

The selling and accounting side assumes nothing about what you sell. The extras your trade needs — an optician’s prescription and lens boxes, for instance — only appear for the shops that need them, so a pharmacy and an optician can run the very same software.

Books, not just a drawer

Invoices, expenses, cheques, debts owed and owing, payroll, and profit sit beside the sale, so the day closes against a report built from the records themselves rather than a total someone typed in.

Ten languages, right to left included

Every screen is translated into ten languages, Arabic and Urdu among them, and the document direction flips with the language instead of leaving mirrored layouts to chance.

Records in and out as spreadsheets

A shop arriving from paper or another system imports its customers and stock as a spreadsheet, and can take the same records back out, edit them in bulk, and return them.

Store Flow

From opening the shop to closing the month

The flow follows the working day rather than a menu tree: staff record what actually happens, and the reports are derived from those records instead of being maintained alongside them.

  1. Onboard the shop, importing existing customers and stock from a spreadsheet.
  2. Ring up sales at the counter, scanning stock or searching the catalogue.
  3. Record expenses, cheques, and what customers still owe as they come up.
  4. Close the day against a report computed from the day’s records.
  5. Close the month into a stored snapshot the books can be audited against.

Data and Compliance

A shop’s records stay the shop’s

Your shop only ever sees your shop. Another business on the same system cannot reach your sales, your customers or your books — that separation is built into the software itself, not left to a setting someone could switch off. You choose where your records are kept, and you can export the lot as spreadsheets whenever you want.

How much usage information gets recorded, and how long it is kept, is set up when your shop is added — and it should be checked against the rules where you trade before you go live. The privacy policy and terms below spell out exactly what is stored about your account, your records and your plan.

Under the bonnetHow it is built. Only interesting if you work in software — nothing here changes what the product does for you.

Tenancy, money, and numbering done at the right layer

Trust POS is a multi-tenant product handling other people’s money, so the parts that are expensive to get wrong later — store isolation, currency arithmetic, and document numbering — are enforced in the data layer rather than trusted to each screen.

Angular 22 and Ionic 8
One responsive codebase for desktop and mobile browsers.
Self-hosted API
Node, Express, and MongoDB, deployable on the operator’s own infrastructure.
Tenancy in code
Every query is pinned to the signed-in store at the data-access layer, not left to a rules file.
Validated payloads
Schemas strip unknown keys on the way in, so a client cannot inject store ids, roles, or sequence numbers.
Integer money
Amounts are held in the currency’s minor unit, so nothing drifts between the till and the ledger.
Server-side numbering
Invoice and receipt numbers are allocated atomically server-side, never computed by a client.
Live updates
Socket.IO over database change streams pushes record changes to open screens, in per-store rooms.
Metered plans
Call volume is counted per organisation in Redis; at the cap, writes pause and lookups keep working.

Put the counter and the books in one place

We build business software where the money adds up and the reports come from your real records — sorted properly from day one, not patched on later.