Industry
Software engineering for Retail
Retail technology looks simple from the outside and is brutal underneath: the hard part is keeping stock, orders and customers consistent across the shop floor, the website and the app, and staying up when everyone shops on the same weekend. We build for that reality, and we are honest that stitching legacy POS, ERP and e-commerce together is usually messier than any greenfield build.
Why the domain matters
Retail software has one defining problem, and almost everything else is a consequence of it: the same product is sold through more than one channel, and those channels have to agree. A customer sees an item online, checks it is in their local shop, reserves it for click-and-collect, changes their mind and returns it to a different store entirely. For that ordinary journey to work, the till, the website, the app and the warehouse all have to share one honest view of what stock exists, where it is, and who owns which order. Most retail failures are not exotic: they are two systems quietly disagreeing about a number.
The second defining problem is that retail does not spread its load evenly. A system that is comfortable for eleven months of the year meets Black Friday, the Boxing Day sales and the Christmas run-up and has to absorb a multiple of its normal traffic in a few hours, often with a marketing campaign deliberately pointing a firehose at it. Peak is not an edge case to handle later; it is the load the architecture has to be designed around, because the day it fails is the day the year’s margin is made. Getting inventory consistency and peak resilience right is most of the job.
We are senior engineers who build and then operate retail systems, and we will be blunt about the least glamorous truth in this sector: the hard part is rarely the new thing you want to build. It is the existing estate: the POS that was installed a decade ago, the ERP that is the real system of record for stock, the e-commerce platform bolted on later, the spreadsheet that finance secretly relies on. Making those talk to each other reliably is where retail projects actually live or die, and we would rather tell you that at the start than discover it together in November.
The challenges in retail
A single source of truth for stock is genuinely hard
Every channel wants to know one number: how many of this do we have, and where. The moment that number lives in more than one system (the POS, the warehouse, the website), they drift. A sale in-store that the website learns about ten minutes late is an oversell waiting to happen. The engineering challenge is not storing stock; it is deciding what the authoritative source is, how fast every channel reconciles to it, and what happens in the gap. Most retailers we meet have three answers to “how much stock do we have” and no agreement on which is right.
Peak load is the design constraint, not a tuning exercise
Black Friday and the Christmas period can put five or ten times normal traffic through the same systems in a single afternoon, and a promotion can concentrate it into minutes. Systems that are fine at average load fall over precisely when every sale counts: checkout times out, stock counts lock up, the payment queue backs up. You cannot bolt resilience on in October; the caching strategy, the way stock is decremented, the database contention on hot products all have to be designed for the spike from the outset.
The legacy estate is messier than any greenfield
Retailers rarely start from nothing. There is an incumbent POS, an ERP that finance and buying depend on, an e-commerce platform added later, maybe a separate warehouse system. Each has its own data model, its own idea of a “product”, its own quirks and outages. Integrating them is where the real effort goes, and it is unglamorous, defensive work: reconciling SKUs, handling partial failures, coping with a nightly batch that used to be “good enough”. Anyone who quotes you a clean omnichannel build without accounting for this is not being straight with you.
Oversells, overselling and phantom stock erode trust
Nothing damages a retailer faster than selling something it cannot deliver. Oversells happen when channels decrement stock at different speeds, when returns are not put back accurately, or when a warehouse count drifts from reality. Each one is a cancelled order, a refund, a support contact and a customer who trusts you a little less. The fix is not a bigger warning banner; it is consistent, timely stock movements and a considered policy for how much you are willing to promise against uncertain counts.
Fulfilment routing is a real optimisation problem
Once you sell online and hold stock in dozens of shops, every order raises a question: where should it be picked from? The nearest store, the one with excess stock, the warehouse, or a split across several? Getting this wrong ships slower, costs more, and strands stock in the wrong place for the next customer. It is a genuine optimisation problem dressed up as a simple lookup, and treating it as an afterthought quietly bleeds margin on every order.
Payments and PCI scope are unforgiving
Retail takes card payments across tills, terminals and the web, and card data attracts both fraud and the full weight of PCI DSS. Handle it carelessly and you pull your entire estate into a costly, high-risk compliance scope; handle it well and you keep raw card data out of your systems entirely. Retailers also carry chargebacks, refunds and reconciliation across every channel. The money has to tie out between the till drawer, the terminal, the acquirer and the ledger, every single day.
What we build for retail
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Omnichannel and order management platforms
The system that ties the channels together: one order lifecycle whether a purchase starts online, in-store or in the app, with click-and-collect, buy-online-return-in-store, endless-aisle and ship-from-store handled as first-class flows rather than bolt-ons. We build the order management layer that decides where an order is fulfilled from, tracks it through pick, pack and collect, and keeps the customer’s view and the operational view in step.
Inventory and stock management across locations
A single, authoritative view of stock spanning warehouses and every shop, with the movements (sales, receipts, transfers, returns, adjustments), reflected quickly enough that channels can trust the number. We build the stock ledger, the reconciliation against physical counts, and the availability logic that decides what each channel is allowed to promise, so overselling stops being a routine occurrence.
POS and in-store systems
Point-of-sale that behaves on the shop floor: fast at the till, sensible when the network drops, and honestly connected to the rest of the estate rather than an island that reconciles overnight. This is the work behind our dedicated POS development service, tills, payment terminals, returns and exchanges, and the real-time link to central stock and customer records that makes true omnichannel possible.
Loyalty and personalisation
Loyalty schemes and personalisation that work because they see the customer across every channel, not just online. A single customer record that recognises the same person at the till and on the app, points and rewards that behave consistently, and recommendations grounded in real purchase history. We build the data foundation first, because personalisation on top of a fragmented customer view just produces confident nonsense.
Retail analytics and reporting
The reporting that buying, merchandising and finance actually run the business on: sales by channel and store, stock turn, sell-through, margin, and the peak-trading dashboards that tell you what is happening while it is happening. We build the pipelines that pull clean data out of the operational systems and the dashboards that make it usable, without asking anyone to trust a spreadsheet nobody can reproduce.
E-commerce integration and the digital channel
The web and app storefront wired properly into stock, orders, payments and fulfilment, whether that is a headless build or an integration onto a platform you already run. This sits alongside our e-commerce work as an adjacent concern; here the emphasis is on making the online channel a consistent citizen of the wider estate rather than a separate silo that happens to share a logo.
Where we help
Click-and-collect and buy-online-return-in-store
The flagship omnichannel journeys, and the ones that most ruthlessly expose data inconsistency. Reserving stock at a named store, holding it reliably, notifying the customer, handling the collection at the till, and taking a return in a shop for something bought online: each step needs the same customer, order and stock record visible everywhere. We build these as end-to-end flows, not as two systems pretending to cooperate.
Ship-from-store and fulfilment routing
Turning shops into miniature distribution centres so an online order can be picked from wherever stock actually sits. That means the routing logic to choose the best source (proximity, stock cover, capacity, cost), plus the in-store picking workflow and the stock movements that follow. Done well it speeds delivery and clears stranded stock; done badly it just exports warehouse problems to store staff.
Surviving a Black Friday peak
Load-testing against realistic peak profiles, protecting the hot paths (availability checks, checkout, stock decrement), with the right caching and contention handling, and having a rehearsed plan for graceful degradation when a dependency slows. The goal is boring: the day the marketing team has been building towards for months passes without a war room, because the system was designed for that day rather than the average one.
A unified customer and loyalty view
Recognising the same person whether they buy at the till, on the web or in the app, and letting loyalty, history and preferences follow them across all three. We build the identity resolution and the single customer record that make this real, so that “we can see you shopped in-store last week” is a true statement and not a marketing aspiration built on disconnected databases.
How we build for retail
We start by finding the real system of record for stock, and for the customer, and for orders, because in an existing retail estate these are rarely where people assume. Very often the ERP is the true stock authority and the website is downstream of it; sometimes it is the other way round, and sometimes nobody can say. Settling this is not a formality; it decides the entire integration design, and getting it wrong means every channel argues with a different source.
We design for peak from the first architectural decision, not as a hardening sprint before Christmas. That shapes how stock is decremented under contention, what is cached and for how long, where the database hot spots on popular products will be, and how the system sheds load gracefully rather than collapsing. We would rather build the average-day system slightly differently now than rewrite the checkout path in November.
We treat the legacy integration as the main event, because it usually is. That means mapping the SKUs and product models honestly across systems, designing for partial failure so one slow dependency does not take down the till, and being disciplined about which nightly batches can stay batch and which genuinely need to become real-time. We are candid when an incumbent system’s limits, not our design, are the real constraint.
We make stock consistency an explicit, measured policy rather than an accident of timing. How fast does each channel reconcile to the source of truth? How much are you willing to promise against a count that might be stale? What happens to a reservation that is never collected? These are business decisions with engineering consequences, and we surface them rather than letting the defaults decide silently.
Because we operate what we build, we design for the trading day and the incident, not just the demo. Dashboards that show what is happening during peak, alerting on oversells and reconciliation breaks, runbooks for a payment terminal outage or a warehouse feed going quiet. The teams who skip this find out where the gaps are during their busiest hour, which is the worst possible time to learn.
The compliance landscape for retailers
Payments sit under PCI DSS, and the single most consequential decision a retailer makes is how much of its estate falls into scope. Card data flows through tills, payment terminals and the website, and if raw card details touch your systems, your PCI obligations (and your risk), expand across the whole estate. The honest engineering goal is almost always to keep primary account numbers out of your systems entirely, using point-to-point encryption on terminals and tokenisation online, so that what you store is a token and your scope stays minimal.
Consumer protection law shapes a surprising amount of the software. UK consumer rights, the Consumer Contracts Regulations and distance-selling rules govern returns, refunds, cancellation windows and how clearly price and delivery terms are shown. These are not just policy documents for the legal team; they translate directly into how the returns flow, the checkout and the order-cancellation logic have to behave, and getting them wrong is both a compliance and a trust problem.
Data protection under UK GDPR and the Data Protection Act applies squarely to the customer data that loyalty and personalisation depend on. Purchase history, contact details, marketing consent and profiling all carry obligations: lawful basis, data minimisation, retention limits and the customer’s rights over their own data. Personalisation that quietly hoovers up everything is a liability; we build the consent and retention handling in rather than treating it as a later clean-up.
Marketing and electronic communications fall under PECR as well as GDPR, which governs email, SMS and cookie-based tracking. The consent mechanics (how opt-ins are captured, how preferences are honoured, how tracking is gated), have real engineering substance, and a loyalty or marketing platform that treats consent loosely creates exposure that surfaces at the worst time.
To be clear about the boundary: we are the engineering partner, not your legal or compliance adviser. We build software that implements the controls and policies your qualified advisers define (PCI scope decisions, returns policy, data retention, consent handling), and that stands up to scrutiny. The definitive judgement on what the law requires of your business comes from people qualified to give it, and we will build to their requirements rather than improvise our own.
The retail integration stack
The POS is where the physical business meets the digital estate, and integrating it well is deceptively hard. Tills need to be fast and to keep serving when the network wobbles, while still feeding sales, returns and stock movements back to the centre promptly. Many incumbent POS systems were built to reconcile overnight, not to participate in real-time omnichannel, and closing that gap (or working honestly within it), is a large part of any retail integration.
The ERP or stock system is frequently the true source of record for inventory, purchasing and finance, and everything else has to reconcile back to it. Its data model, its update cadence and its batch windows often dictate what the rest of the architecture can promise. We map to it carefully rather than assuming it behaves like a modern API, because in practice it usually does not, and pretending otherwise is how oversells creep in.
The e-commerce platform (whether a hosted platform you already run or a headless storefront), is the digital shopfront that has to share stock, pricing, orders and customer data with everything else. The integration quality here largely determines whether online feels like part of the business or a bolted-on silo, and webhook reliability, catalogue synchronisation and order hand-off are where the effort concentrates.
Payment terminals and gateways span the in-store and online worlds, each with their own semantics for authorisation, capture, refunds and settlement. Doing this well means respecting how each actually behaves. The terminal that goes offline, the gateway that returns an ambiguous status, the refund that has to tie back to the original sale, and reconciling the money across channels daily so the till, the terminal and the ledger agree.
Warehouse and logistics systems close the loop: warehouse management for picking and packing, and carrier integrations for delivery, tracking and returns. Fulfilment routing, dispatch and the returns journey all depend on these talking cleanly to order management. We treat reconciliation between stock, orders and the physical movement of goods as a permanent, automated process, because when the records and the reality diverge, you have a stranded-stock and a cancelled-order problem, not merely a technical one.
Security for retail systems
Card payments make retailers a standing target, and the most important security decision is architectural: keep raw card data out of your systems. Point-to-point encryption on in-store terminals and tokenisation online mean primary account numbers are captured and vaulted by your payment provider, and what you hold is a token. This is the difference between a manageable PCI DSS scope and an expensive, high-risk one, and the honest default is to stay out of scope wherever the design allows.
Retail attracts fraud across every channel: card-not-present fraud online, promotion and loyalty-points abuse, refund and returns fraud, account takeover on customer accounts, and gift-card fraud. Defending against this is real-time work at the decision points that matter: checkout, account login, high-value refunds, unusual ordering patterns. We build the instrumentation and controls in rather than treating fraud as something to notice after the money has gone.
Customer data is both an asset and a liability. Loyalty schemes and personalisation accumulate purchase history, contact details and behavioural data, all of which must be encrypted in transit and at rest, minimised to what is actually needed, and retained no longer than is justified. You cannot leak what you never stored, so we design for data minimisation and sensible retention from the start rather than accumulating everything and hoping.
The in-store environment carries its own risks that head-office security models often overlook: point-of-sale terminals in public spaces, staff devices, shop networks and physical access to hardware. Least-privilege access, hardened endpoints and a clear separation between the shop-floor network and the rest of the estate all matter, because an attacker who reaches a poorly isolated till should not thereby reach the customer database.
Around all of this sits operational security: least-privilege access across systems, comprehensive and tamper-evident audit logging, rehearsed incident response, and regular penetration testing across both the web estate and the in-store footprint. Because we operate what we build, these are not documents we hand over and forget. They are the controls we depend on ourselves when a busy trading day turns into an incident.
What changes
One honest view of stock and customer
Channels that agree, because there is a defined source of truth for stock and for the customer and everything reconciles back to it quickly enough to be trusted. Overselling, phantom stock and “which system is right” arguments stop being a routine cost of doing business and become the exception you can investigate.
A peak you can trade through calmly
A system designed for the Black Friday and Christmas load rather than the quiet Tuesday, so the busiest hours of the year pass without a war room. Checkout holds up, stock counts stay consistent under contention, and the day the margin is made is not the day the architecture is tested for the first time.
Legacy systems that finally cooperate
The incumbent POS, ERP and e-commerce platform integrated so they share stock, orders and customers reliably, with partial failures handled and reconciliation automated. The estate stops being a set of silos held together by nightly batches and manual spreadsheets, and starts behaving like one business.
What we build for retail
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for retail?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in retail choose us
Senior engineers who have traded through a peak
Retail punishes juniors-run-the-project staffing, especially when peak arrives. Our people are senior engineers who understand stock consistency, fulfilment routing and the specific ways omnichannel systems fail under load, because they have operated them through real Black Fridays, not just read about them.
We operate what we build
We do not hand over an omnichannel platform and walk away before the Christmas run-up. Living with the oversell alerts, the reconciliation breaks and the peak-trading dashboards is exactly why we take the unglamorous consistency and resilience work seriously from the first commit.
Honest about the legacy mess
We will tell you plainly that stitching your existing POS, ERP and e-commerce together is usually harder than any greenfield build, and we will scope the integration for what it really is rather than quoting you a clean omnichannel fantasy. We would rather set an honest expectation now than discover the batch job that cannot go real-time in November.
Engineering that stays in its lane
We are the engineering partner, not your legal, compliance or PCI advisers. We implement the PCI scope decisions, returns policy, data retention and consent handling your qualified people define, and build software that survives scrutiny, and we are explicit about where our responsibility ends and theirs begins.
Related sectors
Adjacent sectors we also know.
Common questions
What is actually the hard part of building retail software?
It is rarely the new feature you have in mind. The two things that consistently make retail hard are data consistency across channels: keeping stock, orders and the customer record in agreement between the till, the website and the warehouse, and surviving seasonal peak, when Black Friday and Christmas put several times your normal load through the same systems. Underneath both sits the messiest reality of all: integrating an existing POS, ERP and e-commerce platform that were never designed to cooperate. We scope projects around those truths rather than around the shiny parts.
How do you stop overselling across online and in-store?
By deciding, explicitly, what the authoritative source of stock is and how fast every channel reconciles to it, then designing the stock movements so sales, returns, transfers and adjustments are reflected quickly enough that channels can trust the number. We also make it a deliberate policy how much you are willing to promise against a count that might be slightly stale, and how reservations and uncollected click-and-collect orders behave. Overselling is usually a timing-and-ownership problem, not a bad-luck problem, and it is fixable once those decisions are made rather than left to chance.
Can you make sure our systems survive Black Friday?
We design for peak from the outset rather than hardening in a panic beforehand. That means load-testing against realistic peak profiles, protecting the hot paths (availability checks, checkout and stock decrement), with the right caching and contention handling, and building in graceful degradation so a slow dependency does not collapse the whole checkout. We cannot promise the laws of physics away, and we will be honest about where an incumbent system is the limiting factor, but the aim is that your busiest day passes without a war room because the architecture was built for it.
We already have a POS and ERP, can you work with those?
Yes, and in most retail projects that is the majority of the work. We map the product and stock models honestly across your existing systems, design for partial failure so one slow or offline dependency does not take down the till, and are disciplined about which nightly batches genuinely need to become real-time versus which can stay batch. We reference our POS development work directly for the in-store side. We will also tell you candidly where an incumbent system’s limits, rather than our design, are the real constraint, so you can decide with clear eyes.
How do you handle payments and PCI DSS across tills and online?
The core principle is that raw card data should never touch your systems. In-store we use point-to-point encryption on the terminals, and online we use tokenisation, so that primary account numbers are captured and vaulted by your payment provider and what you store is a token, not a card. That keeps your PCI scope minimal across the whole estate rather than pulling every till and server into it. We also build the daily reconciliation so the till drawer, the terminal, the acquirer and your ledger tie out. The definitive PCI scope decisions belong with your qualified advisers, and we build to them.
Building for retail?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if retail is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.