Custom POS vs Off-the-Shelf: When Square and Lightspeed Stop Fitting

Square, Lightspeed, and Shopify POS solve the common case well — they're battle-tested, supported, and integrate with the accounting and inventory tools most retailers already use. The overhead of a custom build is only justified when the common case genuinely doesn't fit.

This is worth stating plainly because the custom software industry has an incentive to make off-the-shelf solutions sound inadequate. They're not. For most retailers — standard SKUs, straightforward pricing, single location, no compliance requirements — Square or Shopify POS is a better choice than a custom build. The setup is faster, the support is better, the integration ecosystem is mature, and the cost is a predictable subscription rather than a capital expenditure.

The cases where a custom build is genuinely justified are specific and recognisable. They're not about preference for a custom aesthetic or dissatisfaction with a particular UI element. They're about structural limitations in the data model that produce real operational problems — inventory errors, compliance failures, staff workarounds — that compound over time and become increasingly expensive to manage.

When a product has four or five defining attributes — finish, wattage, size, compatibility — and the combinations aren't just SKU variations but genuinely different pricing and stock units, most POS systems force you into workarounds. We've built a lighting retailer's POS where this was the exact operating reality.

Lightspeed and Square both support product variants. Their variant models work well for fashion retail (size × colour), for basic electronics (storage × colour), and for most standard retail product structures. They fail when the product has more than two or three independent variant axes, when different variant combinations have structurally different pricing (not just price overrides), or when the variant matrix is sparse — where most combinations don't exist as actual products.

A lighting retailer with the product attributes we described (finish, wattage, size, compatibility) has thousands of theoretically possible combinations, but only a few hundred actual products. The variant matrix is sparse. Standard POS systems require you to create every variant as a product record — including the ones that don't exist — or to use workarounds (custom fields, serialised SKUs) that make inventory tracking unreliable.

The custom solution: a product data model that represents attributes and variants as first-class entities, with explicit stock records only for combinations that actually exist. The checkout flow resolves attributes in sequence (customer selects finish, system shows available wattages given that finish, customer selects wattage, system shows available sizes, and so on) rather than presenting an undifferentiated dropdown of all variants. This is a different data model from anything off-the-shelf POS provides — it's a schema decision, not a configuration one.

Pharmacy, healthcare, and some food retail have reporting requirements — batch-level expiry tracking, controlled-substance logs, cold-chain documentation — that need to be designed into the data model from day one. Our custom POS system for pharmacy is a concrete example of this. Bolting these requirements onto an off-the-shelf system produces fragile workarounds.

The compliance problem is not that off-the-shelf POS systems can't produce compliance reports. Some of them can, through add-ons and integrations. The problem is that an add-on compliance layer reads data from a transaction system that wasn't designed to produce compliant data. The result is reports that are mostly correct but have gaps — a batch number that wasn't recorded, a staff authorisation that wasn't logged, a controlled substance that was processed through the standard checkout rather than the controlled-substance workflow because the standard checkout was faster.

A purpose-built compliance schema makes the compliant path the mandatory path. You cannot process a controlled substance sale without recording the batch number and the authorising staff member, because the transaction form doesn't have a completion path that doesn't include these fields. The compliance data isn't captured by a separate layer — it's part of the core transaction record.

This design principle — making the compliant path the only path — is the architectural difference between a POS that passes a regulatory examination and one that doesn't.

Off-the-shelf systems handle multi-location reasonably well for simple retail. When stock transfers between branches involve approval workflows, or when each branch operates under different pricing and discount rules, the limitations surface quickly.

Lightspeed and Shopify POS both support multi-location inventory. For simple multi-branch retail — the same products at all locations, the same pricing, straightforward stock transfers — they work well. The limitations appear when the business has operational complexity that the platform's multi-location model doesn't account for.

Approval workflows for inter-branch transfers are the most common limitation. An off-the-shelf system's transfer workflow is typically: branch A initiates a transfer request, branch B receives and confirms. A retailer with a centralised purchasing team and branch-level inventory accountability needs: branch A initiates a transfer request, purchasing manager reviews and approves, branch A processes the pick, branch B receives and reconciles. The four-step approval workflow with different actors at each step isn't in the off-the-shelf playbook.

Per-branch pricing is the second. A retailer that operates branches in different markets — different cost bases, different competitive environments, different promotional calendars — needs per-branch pricing that can be managed centrally but applied locally. Most off-the-shelf systems support price overrides by location, but the management overhead of keeping these aligned is significant at scale.

Discovery and workflow mapping, data model design, hardware integration, role-based permissions, and staff training. Timeline: typically 12–20 weeks depending on branch count and compliance requirements. It's not a web app with a payment field — it's a system that has to work under real-world counter conditions.

The most underestimated part of a custom POS build is the counter conditions requirement. A web application can tolerate a 2-second load time. A POS checkout cannot. Staff are operating under customer-facing time pressure, and a system that feels slow — even if it technically performs — creates frustration that leads to workarounds. Performance requirements for a POS are more stringent than for internal tools, which means more careful architecture and more extensive performance testing.

Hardware integration is the second underestimated component. Receipt printers, barcode scanners, cash drawers, and card payment terminals all need to integrate reliably with the software. These integrations are not complex in isolation, but they need to work correctly under the full range of operating conditions: different cable standards, different firmware versions, network reliability issues in retail environments, and the need for graceful degradation when hardware fails mid-transaction.

Staff training is the component that determines adoption. A technically excellent POS that staff find confusing will be abandoned in favour of workarounds within weeks. Training should include both the initial deployment training and a documented quick-reference guide for the most common transaction types. Counter staff who understand the system well perform faster, make fewer errors, and use override functions correctly rather than as shortcuts.