Point of sale, payment terminals, RFID and NFC cards, and the cloud that keeps every branch in agreement — including when the connection drops. This is our deepest production track record: the POS platform we architected runs in more than 10,000 retail stores and carries over $50M in annual transactions.
A till that works on the counter, a cloud that every branch reports into, and hardware that behaves. Not a demo on a laptop. Concretely:
Two of those items carry most of the value and are the two most often skipped. Idempotent payment handling is what stops a customer being charged twice when a terminal times out and the cashier presses the button again. Audit logging is what lets you answer, three months later, exactly what happened at that till at 19:42. Neither is visible in a demo, which is precisely why cheap builds leave them out.
POS is the least forgiving software category an SME buys. It handles money, it runs on hardware, it must work with no connection, and when it fails you are not inconvenienced — you cannot trade. Four architectural decisions in the first two weeks determine whether you have an asset or a liability.
Offline is a data model, not a feature. Whether the device can journal locally, survive a restart mid-shift, and reconcile two tills that sold the last unit of stock is decided by how the local store and sync layer are designed. It cannot be bolted on later without rewriting the core, which is why so many POS rescue projects land on our desk.
Hardware must be abstracted. The common failure is a printer library called from the receipt screen and a card reader SDK called from checkout. It demos fine — then your supplier discontinues a model, or you open a branch in a country with different terminals, and the change touches forty files. On the platform we architected we solved this once with a hardware abstraction layer, which is why new terminals can be certified there without a full application rebuild. We build client systems the same way even when version one supports a single device.
Tenancy must be a real boundary.If "branch" is just a column somebody remembered to filter on, one forgotten query leaks another franchise's numbers. We design the isolation model up front, and configuration dispatch so a chain-wide price change reaches thousands of devices in minutes rather than by asking managers to update manually.
Money movements are append-only. Nothing is quietly overwritten; corrections are new entries. That is what makes disputes, refunds, and end-of-month reconciliation answerable rather than argumentative.
Cheap development shops skip all four because none of them produce a visible screen, and they are paid by the hour for screens. We write the architecture down in plain language first so you can challenge it, then build in increments you can run on real hardware in a real store. We also operate what we ship, which means our own shortcuts cost us too.
No numbers on a web page — but in this category the drivers are unusually concrete, and three of them are decided by your operation rather than by us.
Each terminal, reader, printer, and card type needs physical testing, and payment providers impose their own certification process with their own calendar. This is frequently the longest single item and it is outside anyone's control — which is why we ask for exact model numbers on the first call.
One shop, one role, is a contained project. Multiple branches with head-office reporting, franchise separation, and cashier / supervisor / manager / owner permissions is a platform. Phasing one branch live first is almost always the right call.
Standard retail selling is well-trodden. Weighted goods, kitchen routing, table service, deposits and returns, membership tiers, stored-value balances that must behave correctly offline — each adds real work, and each is usually the reason you left off-the-shelf.
Local payment rails, your accounting platform, inventory or ERP, tax and e-receipt requirements. Modern documented APIs are days; an older on-premise system or a provider with a slow approval process adds weeks that have nothing to do with the POS itself.
As a rough shape: replacing one store's defined workflow with custom POS on hardware you already own is a contained build of a couple of months. A multi-branch, offline-first system with payment terminals, card issuance, and back-office reporting is a multi-month engagement. We phase these deliberately — one store trading on the new system while the rest is still being built is worth far more to you than a big-bang launch.
Fashion, convenience, electronics, and pharmacy operators who need one view of every branch, chain-wide price changes that actually land, and stock that agrees between shop floor and head office. Frequently paired with an Android staff app for stock counts and transfers.
Restaurants and cafés needing table or counter service, kitchen routing, split bills, and shift reconciliation — plus a loyalty or stored-value card that works when the WiFi in the back room does not.
Bus and shuttle operators using QR payments and tap cards on vehicles that spend the day out of coverage. Offline balance rules and anti-fraud handling on a card tapped in two places are the real engineering here.
The same architecture carries into IoT work more broadly: devices at the edge, one cloud underneath, and AI on top reading the resulting transaction data for forecasting, stock alerts, and branch profitability. That last layer is usually what turns a POS from a recording system into something that helps run the business.
This is the category where we have the most to point at. The POS platform our founding engineer architected serves more than 10,000 active retail stores across fashion, food and beverage, electronics, and pharmacy, and carries over $50M in annual transactions — offline-first, multi-tenant, with payment hardware behind a single abstraction layer. On the same architecture we have built RFID and NFC payment cards, payment terminal integrations, and smart bus ticketing with QR payments. You can also see what happens to the data afterwards in our own CEO's Cockpit dashboard — live, fictional data, no registration.
Offline-first point of sale, multi-tenant cloud, and a payment-hardware abstraction layer carrying $50M+ in annual transactions.
A React Native marketplace with multi-currency settlement and bilingual listings, shipped to both app stores.
Plainly, so you do not waste a month finding out:
Android apps and on-device software for staff, drivers, and counters — including hardware-attached builds on scanners, printers, and payment terminals.
Internal platforms, customer portals, dashboards, and marketplaces — the system your business runs on, not a brochure website.
AI agents, document pipelines, and LLM features that remove a named piece of manual work — with a human approval step and an audit trail.
For most single-site shops you should buy off the shelf, and we will say so. Custom starts to pay when your operation does not fit the box: unusual pricing or membership rules, a workflow that spans branches, hardware or a payment rail no vendor supports locally, per-transaction fees that have grown into a serious annual cost, or a need to feed the data into your own systems. If none of those apply, keep your money.
Yes — this is the single most important requirement in the category and where cheap builds fail. Every transaction is written to the device first and journaled locally, then synced to the cloud when the connection returns, with duplicate and conflict handling so nothing is lost or double-counted. The platform we architected runs in more than 10,000 stores, many in areas with unreliable connectivity, and a POS that stops selling on a network drop is commercially unacceptable.
Usually yes. We work with the hardware ecosystems our clients already use rather than pushing you onto a device family that suits us, and we build a hardware abstraction layer so device-specific code never leaks into the application. That is why on the POS platform we architected new terminal models can be certified without rebuilding the app. Send us the exact model numbers early — SDK availability and certification requirements decide the timeline.
Yes — stored-value and membership cards, staff cards, and tap-to-pay flows, including the card issuance and top-up side, not just the reader. We have built RFID and NFC payment cards and smart bus ticketing with QR payments on the same architecture. The parts people underestimate are the offline balance rules and the anti-fraud handling when a card is tapped in two places, and those are design decisions made at the start.
You own all of it — code, cloud accounts, store listings, in your company name from the first day. On timeline, a single-store POS replacing a defined workflow is a matter of a couple of months; a multi-branch, multi-tenant system with offline sync, payment hardware, and back-office reporting is a multi-month engagement that should be phased so one branch goes live before the rest. Certification with payment providers is often the longest single step and is outside anyone’s control.
That is normally the reason a business builds custom in the first place. We integrate with major accounting platforms, ERP, and inventory systems so a day’s sales become entries without anyone retyping them, and we can feed the same transaction data into AI reporting — demand forecasting, stock alerts, branch profitability. Where a system has no usable API we tell you what the workaround costs before you commit.
We do, under an agreed support arrangement, because a POS failure is lost revenue in real time rather than an inconvenience. That covers monitoring on the sync layer and payment flows, device and OS updates, new hardware certification, and a defined response time. This is also the honest reason we are not the cheapest option: we price for still being here when the thing breaks.
A 30-minute call with an engineer, in English or Japanese. Bring your device models and your branch count, and we will give you an honest read — including when you should buy off the shelf instead.