Custom Software for Retail — Omnichannel, Built Secure, Built to Ship

Brick-and-mortar and omnichannel retail is not pure e-commerce. You are reconciling a physical shelf against an online cart, a card-present terminal against a tokenized web checkout, and a Black Friday spike against a back-office EDI feed that still runs on a supplier's schedule. The two things that quietly sink retail software are inventory that lies — an oversell on the busiest day of the year — and a checkout that buckles under load. Off-the-shelf SaaS papers over both until you hit your own edge cases, and a contractor who has never reconciled a cycle count learns it on your floor.

We build with those realities in mind from the first architecture diagram. Inventory lives in one service as the source of truth, fed by webhook-driven events from each POS and the storefront, with stock reservations on checkout and idempotent adjustments so retries never double-count. Card data is encrypted inside the reader with P2PE or tokenized at the edge so your PCI scope stays as small as the hardware allows. And the checkout path is idempotent and queue-buffered so a holiday surge degrades gracefully instead of overselling or double-charging.

Pure e-commerce has one inventory pool and one checkout. Retail has many of each, and they have to agree. A single order can be placed online, reserved against a specific store's shelf for BOPIS, modified by a return at a third location, and settled across a card-present terminal and a gift-card balance — all of which must produce one coherent customer, order, and inventory record. The moment those views diverge, you get oversells, phantom stock, and refunds that do not reconcile. Unified commerce is fundamentally a distributed-systems problem wearing a storefront.

Seasonality compounds it. Most of the year your traffic is predictable; for a few days around Black Friday and Cyber Monday it is not, and that is exactly when inventory race conditions, non-idempotent checkouts, and uncached catalog pages turn into oversells and outages. The integrations are intricate too: POS vendors like Square, Clover, Shopify POS, and Lightspeed each have their own webhook quirks and rate limits; payment hardware changes your PCI scope depending on whether it does P2PE; and supplier EDI, purchase orders, and barcode/RFID flows all run on their own cadence. Each one has its own failure mode when something breaks at 2 a.m. on the biggest sales day of the year. We have wired this stack and know where the time gets eaten.

PCI-DSS (card-present and online). Any card acceptance puts you in PCI scope, but how much depends on your hardware. A validated P2PE solution or a Stripe Terminal reader encrypts account data inside the device, so the cardholder data never crosses your network in the clear — that can shift a location from the heavy SAQ D-Merchant toward SAQ P2PE or SAQ B-IP. Online, tokenized checkout keeps you in SAQ A or A-EP. We scope the boundary explicitly with your QSA and design POS-adjacent networks to keep the cardholder-data environment small.

CCPA, CPRA, and state privacy. Retail collects a lot of customer data — purchase history, loyalty profiles, contact info — which makes you a controller under CCPA/CPRA and a growing list of state privacy laws. We build consent capture, data-subject-request handling (access, deletion, opt-out of sale/sharing), and retention rules into the data model rather than bolting them on after a regulator asks.

ADA and WCAG. Retail storefronts are a frequent target for ADA accessibility demand letters. We build to WCAG 2.2 AA — keyboard navigation, focus management, semantic markup, contrast, and accessible checkout — as part of the definition of done.

Fraud. Retail fraud is multi-surface: card testing against your checkout, account takeover on loyalty balances and stored value, BOPIS fraud at pickup, and return fraud at the counter. We wire velocity checks, pickup verification, RMA controls, and stored-value protections appropriate to your model — fraud controls are cheaper to design in than to chase after a loss.

POS and back-office exposure. POS terminals, store networks, and back-office systems are a documented breach vector — memory-scraping malware and flat store networks have caused some of retail's largest incidents. We design segmented networks, least-privilege access, and tamper-evident logging, and we recommend penetration testing of the POS-adjacent network, web app, and APIs to find the gaps before an attacker does.

Disclosure and consumer-protection logging. Pricing, promotions, gift-card terms, and return policies all carry disclosure obligations that vary by state. We do not give legal advice — but we build the consent capture, disclosure display, and audit logging your counsel will want when a question comes up.

Next.js 16 on the App Router with React 19 and TypeScript end-to-end. Postgres for the system of record — usually Neon or RDS depending on compliance posture. Prisma or Drizzle as the type-safe ORM. Stripe for card-not-present checkout and Stripe Terminal for card-present, with gift-card and store-credit tender on top. Webhook-driven sync wires the POS (Square, Clover, Shopify POS, Lightspeed) and any ERP into a central commerce hub. Catalog search runs on Typesense or Algolia so browsing stays fast under load. CDN and edge caching front the catalog and content, and Sentry plus Datadog give you observability with PII-aware redaction in the logger.

The pieces that make retail hold up under a holiday spike live in the write path. Redis with BullMQ buffers inventory adjustments and checkout so a surge queues instead of oversells; checkout is idempotent and keyed so retries never double-charge; and stock reservations hold inventory for the length of a cart. Background workers handle EDI document exchange, supplier purchase orders, loyalty accrual, and email/SMS off the request path. The web tier autoscales on Vercel, read replicas absorb browse traffic, and the system degrades gracefully — cached availability keeps the store shoppable even if a write path is under pressure. POS-adjacent networks are segmented, and tender data is tokenized or P2PE-encrypted so the cardholder-data environment stays small.

Three patterns repeat. First, inventory is treated as a number on each system rather than a single reconciled truth. Each POS and the storefront keep their own count, a nightly batch tries to paper over the drift, and on the busiest day of the year a customer buys the last unit twice. By the time you notice, you are issuing apology refunds and eroding trust. Make one inventory service the source of truth and sync everything else to it — retrofitting that later means re-instrumenting every sales channel.

Second, checkout is not idempotent. A shopper's phone drops on a flaky holiday connection, the request retries, and now there are two orders and two charges — or the inventory decrements twice. Idempotency keys on checkout and on every inventory write are cheap to add up front and miserable to add after a Black Friday incident. Design the write path to survive retries from day one.

Third, teams overscope the first release. A new omnichannel program gets pitched with five POS integrations, loyalty, EDI, and clienteling all in v1, and ships a year late serving no one. The realistic build is one POS, one fulfillment mode, and a rock-solid inventory truth — shipped in eight weeks, used through one season, and learned from. We push hard for that scoping discipline because the season does not wait for a nine-month build.

The thing that hurts a retailer is rarely a single bug. It is the oversell on the highest-traffic day, the flat store network that let memory-scraping malware reach the terminals, or the customer database copied by a contractor before the engagement ended. Inventory integrity, PCI scope, and customer-data exposure are the quiet existential risks in retail engineering — and that is exactly why we are US-based, founder-led, and engagement-first on every project.

William Beltz writes or reviews every line of code that touches your inventory, your tender flows, or your customer data. NDAs are mutual and signed before discovery. Source code lives in your GitHub organization, not ours. The handoff is documented for either ongoing collaboration or in-house ownership — your call.

Retail's largest breaches have come through POS-adjacent networks and back-office systems, not just the public website. We run network penetration tests against store and back-office segments to find flat networks, weak segmentation, and the lateral-movement paths that let an attacker reach the cardholder-data environment from a soft entry point.

On the application side, a web app pentest covers your storefront, admin console, and checkout — card testing, account takeover on loyalty and stored value, and authorization gaps — while penetration testing of your order, inventory, and POS-sync APIs catches the integration-layer flaws that automated scanners miss. Findings come back evidence-backed and audit-ready for your PCI assessor and cyber-insurance carrier.

Inventory as a single source of truth. Every channel — each POS, the storefront, the mobile app — publishes sales and stock events to one inventory service. Available-to-sell is computed per location, reservations hold stock for the length of a cart, adjustments are idempotent, and a reconciliation job settles drift against cycle counts. BOPIS, ship-from-store, and endless aisle all read the same numbers, so the views never diverge.

Webhook-driven sync over polling. POS and ERP systems push events into a central commerce hub through webhooks, with a reconciliation backstop for missed messages. This keeps the hub current without hammering vendor rate limits and gives you one place to apply ordering, deduplication, and retry semantics. The same pattern carries to third-party API integration work across the retail stack.

Queue-buffered, idempotent checkout. Checkout and inventory writes go through a queue (BullMQ on Redis) so a seasonal spike degrades gracefully instead of oversells or double-charges. Idempotency keys make retries safe, read replicas and cached availability keep browsing alive under load, and the web tier autoscales. This is the difference between a holiday weekend that holds and one that trends for the wrong reasons.