One platform, from the front desk to the back office.

Sales, inventory, staff and customer data in one place, on the same codebase as Guru ERP. The till opens from the ERP dashboard rather than from a second sign-in.

The Guru POS sale screen in the public demo, showing a five-line basket with a weighed item, GST per line, the attached customer and the balance due

What a two-system retail business costs

A point of sale and a back office bought separately agree once a day at best, and usually only after somebody has spent an hour making them. Stock is right at stocktake, takings are right after reconciliation, and the gap in between is where the business actually operates.

The second cost is training. Front-line turnover is high, so every hour a new hire needs before their first shift is a recurring expense rather than a one-off.

One codebase, two surfaces

Guru POS is not integrated with Guru ERP. It is the same system: the same item master, the same customer, the same ledger, with a till in front of it. That is why the sale that happens at eleven is in the report the owner reads the next morning without anything having to be transferred.

It has to be usable by frontline staff on their first shift and controlled by management from the back office. Both, or it is not finished.

What it does today.

Everything listed is something the software does now. Nothing on this page is a roadmap item, and there is no roadmap on it either.

  1. Sales

    A basket that handles weighed stock priced off the scale, tax resolved per line rather than on the total, and a member attached before the sale is tendered.

  2. Payments

    Tenders applied one at a time against a balance that falls to zero: cash, card and store credit on one docket, with change calculated as it goes.

  3. Inventory

    Stock moved by sales, receipts, wastage and transfers on the same ledger the ERP reads. There is no second stock figure to reconcile.

  4. Customer management

    History built by the transaction rather than typed in afterwards, because the member is attached at the point of sale.

  5. Reporting

    Gross sales, refunds and tax collected above a payment mix and an hour-of-day trend: the figures a bank settlement is checked against.

  6. Multi branch

    Local operation with one head-office view, filtered by location and by cashier.

  7. Tax documents

    A compliant tax invoice reprintable from the register, carrying the per-line rate and the tax total.

  8. Integrations

    Payment and peripheral hardware treated as equipment that fails rather than as an interface that returns.

How it is put together.

One database, one item master, one customer. A point of sale that keeps its own copy of stock is a second source of truth with a queue in front of it, and the reconciliation job that follows is the thing this product exists to remove.

The integration map and the deployment topology are covered in technical review under NDA rather than on a public page.

What actually gets attacked.

The realistic exposure at a counter is the operator, not the network. Discounts, voids and refunds are where money leaves a retail business quietly, so all three are permissioned actions attached to a named user and reportable by user. That is the control that actually matters at a till.

Ownership, handover and AI governance covers what a procurement or security reviewer usually asks next.

Running, on generated data, at demo.devtechguru.cloud. Sign in as demo.admin / GuruDemo2026!. Generated sample data on a tenant that resets overnight. Change anything.

Engagements built on this platform.

RetailBangladesh

A service retail group

Guru POS on the same codebase as Guru ERP, so the till opens from the ERP dashboard rather than a second sign-in.

ChallengeSales, inventory, staff and customer records were reconciled by hand between the counter and the back office.
ConstraintUsable by frontline staff on their first shift, and controlled by management from the back office. Both, or it is not finished.
StatusIn production

Technology

Frontend
ReactTypeScriptNext.jsDesign systems
Backend
PythonDjangoFastAPINode.js
Data
PostgreSQLMySQLRedisData modelling
Cloud
AWSDockerCI/CDInfrastructure as code

Questions we get asked.

What buyers of this platform ask before a demo.

Can we run Guru POS without Guru ERP?

It is the same codebase, so the back office comes with it whether or not you use every module. What you would be choosing is which modules you switch on, not which of two products you buy.

How long does a new cashier need before their first shift?

The design target is that the sale screen needs no training and everything that can cost money (voids, refunds, discounts) needs a permission. We will not publish a training-time figure, because we have not measured one.

Where to go next

You do not need to arrive with a perfect technical specification.

Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.

Start your build