Skip to content

Software Engineering

POS Development Services

A till that keeps taking payments when the internet drops, because a POS that goes down loses sales in real time. We build offline-first point-of-sale for retail and hospitality, and tell you honestly when Square or Lightspeed would serve you better.

Book a consultationTalk to us

What POS Development means in practice

Who it’s for: Retail and hospitality businesses whose checkout has outgrown a basic till or an off-the-shelf app, because of an unusual workflow, multi-site operation, or the need for one connected system across the shop floor, the website and the back office, and who want honest advice on whether to buy, integrate or build it.

A point-of-sale system is where your business actually takes money, and that changes the engineering priorities entirely. Everywhere else, a few seconds of downtime is an annoyance; at the till, it is a queue of customers with cards in their hands and no way to pay. A POS is not judged on how many features it has: it is judged on whether it still works at the busiest moment of the busiest day, when the broadband has dropped and the card terminal is the only thing standing between you and a lost sale. That is the lens we build through.

The scope of a real POS is broad: processing sales, taking card, contactless and mobile payments through certified terminals, managing a product catalogue and live inventory, printing or emailing receipts, applying discounts and promotions, handling refunds and returns, tracking staff and tills, and feeding a back office that reports on all of it across one site or fifty. Increasingly it also has to be one channel among several: the same stock, prices and customers shared with an e-commerce store and an accounting system, so a sale on the shop floor and a sale online draw down the same inventory rather than two systems that quietly disagree.

We will be straight about build-versus-buy before you spend anything, because for a lot of businesses the honest answer is not a bespoke system. Established POS products (Square, Shopify POS, Lightspeed and their peers), are genuinely excellent for standard retail and hospitality, and they have absorbed years of hard lessons about reliability, hardware and payment compliance that you would otherwise pay to re-learn. Our value is rarely reinventing the till. It is the integration work around one of those products, and bespoke POS only where a genuinely unusual workflow, specialist retail, an unconventional hospitality service model, a process no product on the market fits, makes the standard options fight the business rather than serve it.

What you get

  • An honest build-vs-buy assessment up front, whether an established POS product (Square, Shopify POS, Lightspeed and similar), a product plus integration, or a bespoke build is genuinely right for your workflow, with the reasoning written down
  • Offline-first architecture where the till holds its own local data and keeps processing sales through an internet outage, then reconciles cleanly when the connection returns, treated as the core requirement, not an add-on
  • Payment integration through certified card terminals and processors (card, contactless and mobile), using tokenisation so card data never touches or is stored on your systems
  • Inventory and product catalogue that stay consistent across tills and sites, so stock drawn down at one till is reflected everywhere without someone reconciling it by hand
  • Hardware integration with the physical kit a real counter runs on, card readers, receipt printers, barcode scanners, cash drawers and customer displays
  • Multi-location and back-office reporting, sales, takings, staff and stock rolled up across sites, with each till still fully operational on its own
  • Integration with the systems around the till (accounting, e-commerce and stock), so the POS is one connected channel rather than an island someone re-keys from, and an ongoing support arrangement because we operate what we build

What POS Development does for you

  • It keeps trading when the connection does not

    The defining benefit of a POS built offline-first is that an internet outage stops being an emergency. The till holds its own data, completes sales locally and reconciles later, so a dropped connection at the busiest moment is invisible to the customer instead of being a queue that walks out. For a business that takes money in real time, nothing else on the feature list matters more than this.

  • The counter and the website stop disagreeing

    When the POS shares one inventory and price list with your e-commerce store and your accounting, a sale on the shop floor and a sale online draw down the same stock and land in the same books. That removes the oversells, the manual reconciliation and the two-systems-two-answers problem that omnichannel retail otherwise creates.

  • The compliance burden stays small

    By routing payments through certified terminals and tokenisation so raw card data never reaches your systems, we keep your PCI DSS scope as narrow as it can be. You are not storing card numbers, so the largest and most dangerous class of payment risk simply never lands on you.

Why teams choose us for POS Development

  • We treat offline resilience as the core requirement, not a nice-to-have, because a POS that goes down loses sales the instant it does, and that is the failure a real till is measured against.
  • We give honest build-vs-buy advice with no stake in the answer, for standard retail we will point you at Square, Shopify POS or Lightspeed rather than sell you a bespoke build you do not need.
  • We never store card data, keeping payments on certified terminals and tokenisation, so your PCI scope stays small and the compliance risk stays off your systems by design.
  • We operate what we build, so we design the till for the Saturday rush and the flaky broadband (the real conditions a counter runs in), not just a clean demo on office wifi.

What POS Development includes

The concrete pieces of work this covers, scoped to what your problem actually needs.

  • Offline-first sales processing

    A till that owns its data locally and completes sales without depending on a live connection, then synchronises to the central system when one is available, with conflict handling designed in, so two tills selling the last unit reconcile predictably rather than corrupting the count.

  • Payment and terminal integration

    Card, contactless and mobile payments through certified terminals and payment processors, integrated so the terminal handles the card and your system never sees or stores the number. We wire in the processor, the terminal and the reconciliation, keeping the sensitive part off your kit entirely.

  • Inventory and catalogue management

    A product catalogue and live stock that stay consistent across every till and site, with the discounts, promotions, variants and pricing rules a real shop floor needs, so what a customer is charged and what the stock count says are always the same thing.

  • Hardware integration

    The physical kit a counter actually runs on (card readers, receipt printers, barcode scanners, cash drawers and customer-facing displays), driven reliably from the POS, including the awkward edge cases of a printer that jams or a scanner that drops mid-transaction.

  • Multi-location and back office

    Takings, stock, staff and sales rolled up across every location into back-office reporting, while each till stays fully operational on its own, so head office sees the whole estate and no single site goes dark because the central system did.

  • Omnichannel and accounting integration

    Connecting the POS to your e-commerce store, accounting and stock systems so it is one channel in a connected operation. The same inventory, prices and customers shared across the shop floor and the website, with sales flowing through to the books automatically.

Where it fits

  • Outgrowing a basic till

    A growing shop or venue has hit the ceiling of a simple till or card-reader app. It cannot do the inventory, the reporting or the workflow the business now needs. Often the right move is a capable off-the-shelf POS with the integration built around it; we work out whether that or a bespoke build genuinely fits before committing to either.

  • An unusual hospitality or retail workflow

    A specialist operation. An unconventional service model, a bespoke ordering flow, a process the mainstream products simply do not support: finds every off-the-shelf POS forcing it to work around the software. This is where a bespoke till earns its place, built around the real workflow rather than bending the business to fit a product.

  • Unifying shop floor and online store

    A retailer sells both in person and online but the two run on separate systems, so stock oversells, prices drift apart and someone reconciles by hand. The work is integration: making the POS and the e-commerce store share one inventory and price list so a sale in either channel draws down the same stock.

  • Rolling out across multiple locations

    A business opening or running several sites needs central visibility of takings, stock and staff without any single till depending on head office to trade. We build so each location is resilient and independent on its own connection, while sales and inventory still roll up centrally for the back office.

How we approach POS Development

We start from the failure you cannot afford, which for a POS is losing sales at the counter. Before anything else we settle how the till behaves when the internet is down, because that single decision shapes the whole architecture. A POS that assumes a live connection is a POS that stops taking money the moment your broadband hiccups, and no amount of features makes up for that. So we design local-first: each till owns its data, processes sales on its own, and syncs to the central system when the connection is there, never depending on it to complete a transaction.

From there we are deliberate about build-versus-buy, because the most valuable thing we can do is sometimes talk you out of a bespoke build. For standard retail and hospitality, a proven POS product will beat anything we could write from scratch on reliability and compliance alone, and our honest contribution is the integration around it. We reserve a bespoke build for the genuinely unusual workflow (the specialist process no product fits), and when we do build, reliability and offline resilience come before the feature list, every time.

How we deliver

We begin by understanding how your counter actually works and, just as important, deciding honestly whether you need a bespoke build at all. We map the real workflow: how a sale is rung through, how returns and discounts are handled, what the busy period looks like, what hardware sits on the counter, and how the till connects to the rest of the business. For standard retail and hospitality this discovery often ends with a recommendation to use a proven POS product and integrate around it, and we will say so plainly even though a bespoke build would bill more.

Where a bespoke or heavily integrated system is genuinely warranted, the first architectural decision is the offline behaviour, because it shapes everything downstream. We settle how the till holds data locally, how it processes sales without a live connection, and how it reconciles when the connection returns, including how conflicts between tills are resolved. Getting this right early is the difference between a POS that survives a bad broadband day and one that falls over at the worst possible moment.

From there we build in reviewable cycles against the real hardware, not a simulation, because the printer, the scanner, the cash drawer and the card terminal all have failure modes that only surface on physical kit. We integrate payments through certified terminals so card data stays off your systems, wire in inventory and the back office, and test deliberately against the conditions a counter really faces: a dropped connection mid-sale, a jammed printer, two tills touching the last item at once.

At go-live we are there for the conditions that matter, and afterwards we keep running it. A POS lives at the sharp end of the business, so we hand over documentation your team can use and (because we operate what we build), offer the ongoing support arrangement to maintain it, because a till that fails on a Saturday cannot wait until Monday for someone to care.

Offline-first, local sync and hardware

The single defining architectural choice in a POS is that it must work offline. A till that assumes a live internet connection is a till that stops taking money the moment the broadband drops, and it always drops at the worst time. So we build local-first: each till holds its own copy of the data it needs, processes sales entirely on its own, and treats the network as something that may or may not be there rather than something it depends on to complete a transaction. When the connection returns, the till synchronises with the central system in the background, without the person at the counter ever having to think about it.

That design forces us to take synchronisation and conflict resolution seriously, because two tills operating independently can both try to sell the last unit of stock, or the same record can change in two places while they are apart. We design how those conflicts are detected and resolved so the reconciliation is predictable and the stock count stays honest, rather than the naive approach that quietly loses a sale or corrupts a total when the systems rejoin. This is the genuinely hard part of POS engineering, and it is where offline-first systems are made or broken.

The other half of the architecture is the physical hardware a counter runs on, which is far less forgiving than software people. Card readers, receipt printers, barcode scanners, cash drawers and customer displays each have their own protocols and their own ways of failing mid-transaction: a printer that runs out of paper, a scanner that disconnects, a terminal that times out. We integrate this kit so those failures are handled gracefully rather than freezing the sale, because on a real shop floor the hardware is not an edge case, it is the daily reality.

PCI DSS, payments and physical store security

The cardinal rule of payment security is that the safest card data is the card data you never hold. So we integrate payments through certified card terminals and processors using tokenisation, which means the raw card number is captured and handled by the certified terminal and the processor, never by your systems, and never stored by us. This keeps your PCI DSS scope as narrow as it can be: you cannot leak card numbers you never had, and the largest and most expensive class of payment breach is designed out rather than defended against.

PCI DSS is a genuine compliance obligation for anyone taking card payments, not an optional extra, and the honest way to meet it is to reduce what you have to comply about. By keeping the sensitive card handling on certified, compliant hardware and out of your own environment, we shrink the surface that has to be assessed and audited. We are candid about what still falls to you and design the system so that boundary is clear, rather than quietly leaving card data somewhere it should never be and hoping an assessor does not find it.

Physical and store security matters too, because a POS lives in a public place where staff turn over and the till is a target. We build role-based access so staff, supervisors and managers can do only what their role should (voids, refunds, discounts and cash-drawer access gated appropriately), and so consequential actions leave an audit trail. That trail is both a control against internal fraud, which is a real risk at any till, and the record you need when a takings discrepancy has to be explained rather than argued about.

Signs it’s time

  • You have outgrown a basic till or a simple card reader. You need real inventory, reporting or workflow that the simple setup cannot give you
  • Your workflow is genuinely unusual. A specialist retail or hospitality process that the standard POS products force you to work around rather than support
  • You are selling across channels (a shop floor and an online store), and you need one system where a sale in either place draws down the same stock and prices
  • You are running, or opening, multiple locations and need takings, stock and staff rolled up centrally while every till still works independently on its own connection

Reliability over features, and buy over build

Our whole methodology on POS rests on one uncomfortable truth: reliability matters more than features, because a POS that goes down loses sales in real time. Everywhere else in software you can trade a little robustness for a richer feature set and nobody notices. At the till, the trade is visible immediately, as a queue of customers who cannot pay. So we deliberately prioritise the till working, working offline, and working with real hardware over a longer list of capabilities, and we are willing to have the awkward conversation where that means saying no to a feature that would compromise the reliability the whole thing depends on.

The same honesty drives our build-versus-buy advice, and it usually points away from a bespoke build. Established POS products have absorbed years of hard-won lessons about reliability, hardware quirks and payment compliance that you would otherwise pay to re-learn from scratch, and for standard retail and hospitality they are simply better than anything we could justify writing. Our real value in those cases is the integration around one of them (connecting it to your e-commerce, your accounting and your stock), not reinventing the till itself.

Bespoke POS earns its place in a specific and narrower set of cases: a genuinely unusual workflow, a specialist retail or hospitality process, an omnichannel or multi-location need that no product fits without contorting the business. We will tell you honestly, before you commit a budget, whether you are that case or whether a proven product plus good integration would serve you better and cheaper. Being talked out of a bespoke build you did not need is frequently the most valuable outcome of talking to us.

Technologies we build it with

Chosen per problem, not per fashion. This is the stack we most often reach for on this work.

How we deliver

  1. 01

    Discover

    We map the system, the constraints and the business it serves, including the parts nobody documented.

    Architecture brief

  2. 02

    Architect

    Decisions get made, written down and defended before a line of production code exists.

    Decision records

  3. 03

    Build

    Short cycles against working software. You see progress in the product, not in a status deck.

    Shipping increments

  4. 04

    Operate

    Monitoring, incident response and iteration. The system is alive, so the engagement is too.

    Runbooks & SLOs

Want a straight answer on POS Development?

A short call with a senior engineer, before you write a brief. If POS Development is the wrong answer for your situation, we will say so and tell you what we think is right.

Book a consultationTalk to us

What changes

  • Sales through an outage

    A till that keeps taking payments when the internet drops and reconciles cleanly when it returns, so a broadband hiccup at the busiest moment does not become a queue of lost sales.

  • One connected channel

    Shop floor, website and back office sharing the same stock, prices and customers, so a sale anywhere draws down one inventory instead of two systems that disagree.

  • Payments handled safely

    Card data kept off your systems entirely through certified terminals and tokenisation, so PCI scope stays small and the compliance burden stays where it belongs.

Industries we serve

Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.

How pricing works

  • The build-vs-buy decision is the biggest single driver of cost, and the paths are far apart: integrating around an established POS product, extending one substantially, or building a bespoke till from the ground up each carry very different budgets. The honest first job is establishing which you actually need, because being sold a bespoke build when a proven product would fit is the most common way money is wasted on a POS project, and it is a conversation we would rather have before you spend than after.
  • For work that does warrant building, the real drivers are the offline and sync requirements, the hardware you need supported, and the integration surface. Offline-first with reliable conflict resolution is genuine engineering rather than a checkbox, and it is where the effort concentrates. Supporting more kinds of terminal, printer, scanner and cash drawer adds work, as does every system the POS must connect to (e-commerce, accounting, stock), and how cooperative each of those systems is to integrate with.
  • Multi-location and back-office reporting add scope on top, since rolling takings and stock up across sites while keeping each till independent is more than a single-till system does. We scope the discovery and build-vs-buy assessment as a well-defined piece of work whose output is a recommendation you can act on either way, and (because a POS lives at the sharp end for years), we offer an ongoing support and maintenance arrangement, since we operate what we build.

Typical timeline

  1. 01

    Discovery and build-vs-buy

    Understanding your counter workflow, hardware and integrations, and reaching an honest recommendation on whether to buy a proven POS, integrate around one, or build bespoke. Often the most valuable phase, because it can save the entire cost of a build you did not need.

  2. 02

    Offline architecture and design

    Settling the local-first behaviour first, how each till holds data, processes sales offline and reconciles on reconnect, including conflict resolution, because this decision shapes everything downstream and is where POS systems are made or broken.

  3. 03

    Build against real hardware

    Development in reviewable cycles on the actual terminals, printers, scanners and drawers, with payments integrated through certified terminals, tested against dropped connections and hardware failures rather than a clean simulation.

  4. 04

    Go-live and ongoing operation

    A supported roll-out at real conditions, documentation and handover, then the ongoing support and maintenance arrangement, because a till that fails on a Saturday cannot wait until Monday, and we operate what we build.

What working with us actually means

  • We build for the outage, not the demo

    The mark of a POS built by people who have run one is that it survives a dropped connection at the busiest moment. We treat offline-first as the core requirement and test against the real conditions a counter faces (bad broadband, a jammed printer, two tills on the last item), because that is where a till is actually judged.

  • No stake in the build-vs-buy answer

    We are not tied to selling you a bespoke system, so when we say Square, Shopify POS or Lightspeed would serve you better than anything we could build, it is because it would. That independence is worth more on a POS project than any single technical skill, and it can save you the entire cost of a build.

  • Payments handled the safe way

    We keep card data off your systems entirely, on certified terminals and tokenisation, so your PCI DSS scope stays small by design. You are not defending stored card numbers because you never hold them. The most dangerous class of payment risk is engineered out.

  • We operate what we build

    A POS lives at the sharp end of the business for years, so we design it for the Saturday rush and the flaky connection and stay to run it, because we are the ones who will still be maintaining the till when the busiest day arrives.

How to engage us

Three ways to work with us on this, chosen to fit the problem, not our margin.

Related services

Part of Custom Software Development. Other work we do alongside this.

Common questions

What happens when the internet goes down, does the till stop working?

Not if it is built properly, and this is the whole point of how we design a POS. We build offline-first: each till holds its own local data and completes sales without depending on a live connection, then reconciles with the central system automatically when the connection returns. A POS that stops taking payments the moment the broadband drops is a POS that loses sales in real time, so making the till resilient to an outage is the core requirement we design around before anything else, not a feature we add at the end.

Should we build a bespoke POS or use something like Square or Shopify POS?

For standard retail and hospitality, an established product like Square, Shopify POS or Lightspeed is usually the better choice, and we will tell you so honestly. They have absorbed years of hard lessons about reliability, hardware and payment compliance that a bespoke build would have to re-learn. Our value is more often the integration around one of those products than reinventing the till. Bespoke POS earns its place only when your workflow is genuinely unusual, or your omnichannel or multi-location needs mean no product fits without contorting the business. We work out which case you are in before you spend anything.

How do you keep card payments secure and PCI compliant?

By never storing card data in the first place. We integrate payments through certified card terminals and processors using tokenisation, so the raw card number is handled by the certified terminal and the processor and never touches or is stored on your systems. That keeps your PCI DSS scope as narrow as it can be (you cannot leak card numbers you never held), and designs out the largest and most expensive class of payment breach rather than defending against it. PCI DSS is a genuine obligation for anyone taking card, and the honest way to meet it is to reduce what you have to comply about.

Can the POS share stock and prices with our online store?

Yes, and for a business selling both in person and online this is usually the most valuable part of the work. We integrate the POS with your e-commerce store and accounting so they share one inventory, price list and customer base, meaning a sale on the shop floor and a sale online draw down the same stock and land in the same books. That removes the oversells, the price drift and the manual reconciliation that come from running the counter and the website as two separate systems that quietly disagree.

Can it handle multiple locations without a single point of failure?

Yes, and the design principle is that central visibility must never come at the cost of a till going dark. We build so each location processes sales independently on its own connection, holding its own local data, while takings, stock and staff still roll up centrally into back-office reporting. That way head office sees the whole estate, but no single site stops trading because the central system had a problem. Central reporting and per-till resilience are not a trade-off if the offline-first architecture is right underneath them.

Thinking about POS Development?

Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether POS Development is the right answer here, or what would be.

  1. 01A senior engineer reads it. Not a form queue, and not an account manager.
  2. 02We reply either with questions or with a straight answer that we are not the right fit.
  3. 03If it looks like a fit, a technical call with the person who would actually run the delivery.
  4. 04Then scope, effort and risk in writing, before anyone signs anything.
Or book a free consultationPick a time that suits you. No pitch, no obligation.Prefer email? support@yarqat.com

Two fields required. We reply to real enquiries. No list, no sequence.