Retail Software Development: Inventory, POS Integration, and PIM Architecture for Modern E-Commerce
Retail software development is rarely a greenfield exercise. Almost every retail or e-commerce team already runs a shop system, a payment provider, a logistics partner, and at least one spreadsheet that quietly holds the business together. The real engineering work happens at the seams: keeping stock levels correct across warehouses and storefronts, syncing transactions between physical tills and the online shop, and maintaining one product catalog that feeds five sales channels without contradicting itself.
This post walks through the four components that retail teams most often end up building custom: inventory management, POS integration, product information management (PIM), and order management. For each one, we cover the architecture decisions that matter and give you a framework for deciding whether to build, buy, or integrate.
Why retail software development is an integration problem first
Off-the-shelf shop systems handle the storefront well. Where they fall short is everything behind it. A mid-size retailer with two warehouses, twelve physical stores, and three online channels does not have a "shop problem". They have a data consistency problem: the same product, stock unit, and order exists in several systems, and each system believes it owns the truth.
Custom retail software earns its keep by defining a single source of truth for each domain and building reliable synchronization around it. That principle shapes everything below.
Inventory management: the hardest state machine in retail
Inventory looks simple until concurrency shows up. The core requirements are:
Real-time stock levels across locations. Every warehouse, store, and channel needs a consistent view of what is available. The common mistake is modeling stock as a single integer per product. In practice you need stock per location, plus a computed "available to promise" figure that subtracts reservations, pending transfers, and safety buffers. Model stock movements as an append-only ledger (received, sold, reserved, transferred, written off) and derive current levels from it. The ledger gives you an audit trail for free and makes reconciliation possible when the physical count disagrees with the system.
Reservation logic for concurrent purchases. Two customers adding the last unit to their carts at the same moment is not an edge case, it is Tuesday. Reservations need a defined lifetime (typically 15 to 30 minutes tied to checkout), atomic acquisition (a database-level constraint or row lock, not an application-level check-then-write), and automatic release on expiry. Teams that skip this discover it during their first marketing campaign, when overselling turns into support tickets and refunds.
Automatic reorder triggers. Reorder points per product and location, based on lead time and sales velocity, sound like a nice-to-have. For retailers with thousands of SKUs they are the difference between a purchasing team that manages exceptions and one that manually reviews everything. Start with simple threshold rules; you can layer forecasting on top later once the ledger data exists.
Build, buy, or integrate? Integrate if your ERP already models multi-location stock and your volumes are moderate. Build the reservation and available-to-promise layer yourself if you sell on multiple channels concurrently, because this is exactly where generic systems are weakest and where overselling costs you real money.
POS integration: bidirectional sync with an offline-first constraint
Connecting physical tills to the online platform is where retail projects most often blow their timeline. The difficulty is not the API of the POS vendor. It is the operational reality of a store.
The transaction data model. Design one canonical transaction format that both sides map into: line items with tax breakdown, tender types (card, cash, voucher, mixed), store and till identifiers, and a globally unique transaction ID generated at the till. Sync must be bidirectional: sales flow from the till to the central system (updating stock and revenue), while prices, promotions, and product data flow from the center to the till.
Offline-first operation. Store internet connections fail, and a till that cannot sell because the network is down is an unacceptable failure mode. The till must operate on a local copy of products and prices, queue transactions locally, and replay them when connectivity returns. That decision cascades: transaction IDs must be generated client-side (UUIDs, not database sequences), sync must be idempotent so replayed transactions are not double-counted, and stock updates from offline periods arrive late, which your available-to-promise calculation has to tolerate.
Till reconciliation. At close of day, the counted drawer has to match the recorded tenders. Build reconciliation as a first-class feature: expected versus counted amounts per tender type, discrepancy logging with reason codes, and a report the store manager signs off. Retailers audit this; treat it as a compliance feature, not an afterthought.
Build, buy, or integrate? Buy the till software; the certified fiscal requirements alone (receipt signing obligations vary by country) make building a POS from scratch a poor use of an e-commerce budget. Build the integration layer, because the mapping between the POS vendor's model and your inventory and order systems is unique to your business.
PIM: one catalog, many channels
Product information management is the least glamorous component and the one with the highest long-term payoff. Without it, product data lives partly in the shop system, partly in the ERP, and partly in the marketing team's file share.
The attribute model for configurable products. The core design question is how to model variants. A t-shirt in four sizes and six colors is one product with two variant axes, not 24 unrelated SKUs. Get the hierarchy right early: product family, product, variant, each level carrying its own attributes with inheritance downward. Attribute sets differ per category (a shoe has different fields than a power tool), so the schema must be extensible without migrations for every new category. This is a classic entity-attribute-value versus JSON-column trade-off; in PostgreSQL, a typed JSONB attribute payload validated against per-category schemas tends to age better than a rigid EAV structure.
The media asset pipeline. Every product needs images in different crops, resolutions, and formats per channel. Store originals once, derive renditions on demand or at publish time, and track which asset belongs to which variant and channel. Marketplace channels have hard requirements (background color, minimum resolution) that the pipeline should validate before publication, not after a rejected feed.
Channel-specific pricing and availability. The same product may be priced differently in the web shop, on a marketplace, and in physical stores, and some products should not appear on some channels at all. Model channel as a first-class dimension on price and availability rather than duplicating products per channel. Duplication feels faster in week one and becomes the main source of catalog inconsistencies by month six.
Build, buy, or integrate? Buy or adopt open source (Akeneo is the established option in the PHP ecosystem) if your catalog complexity is the standard variant-and-channel case. Build only if product data is itself your differentiator, for example configurable industrial products with constraint logic that no off-the-shelf attribute model expresses.
Order management: where all the seams meet
The order management layer coordinates everything above, and it is where custom development is most often justified.
Split fulfillment. An order with three items may ship from two warehouses and one store. The order model must support multiple shipments per order, each with its own carrier, tracking, and status, while the customer sees one coherent order. This breaks naive shop-system order models quickly, which is why order orchestration is usually the first component retailers pull out of the shop and into a custom service.
Return handling. Returns need their own state machine: announced, received, inspected, refunded or rejected, restocked or written off. Each transition touches other systems, restocking updates the inventory ledger, refunds hit the payment provider, and rejected returns trigger customer communication. Model returns as first-class objects linked to shipments, not as negative order lines.
Fraud scoring integration. Plugging a fraud provider into checkout is straightforward; deciding what to do with the score is not. Define explicit policies: auto-approve below one threshold, hold for manual review in the middle band, reject above. The manual review queue is a real UI that someone works in daily, so budget for it.
Build, buy, or integrate? Build the orchestration if you have split fulfillment, store-based shipping, or non-trivial return flows. Integrate specialist providers for the commodity parts: carriers, payment, fraud scoring.
A decision framework you can apply tomorrow
For each component, ask three questions in order:
- Is this where we differentiate? If customers choose you partly because of it (delivery speed, product configuration, availability accuracy), lean toward building.
- Does an off-the-shelf option cover 80 percent of our case? If yes, integrate it and build only the missing 20 percent as a layer on top, not a fork.
- What does failure cost? Overselling and till downtime carry direct revenue cost, which justifies custom engineering effort. An imperfect media pipeline mostly costs patience.
The most common expensive mistake is building all four components at once. Sequence them: inventory truth first, because every other component depends on it, then order orchestration, then POS sync, then PIM. If your current stack needs an honest assessment before you commit to that roadmap, a structured code and architecture audit of the existing systems is the cheapest insurance you can buy.
Where Wolf-Tech fits
We have built and scaled retail and SaaS platforms on Symfony and Next.js, including multi-channel inventory systems and order orchestration layers of exactly the kind described here, as part of our custom software development work. If you are weighing build versus buy for one of these components, or your existing retail stack is straining under channel growth, we are happy to talk it through. No pitch deck, just an engineering conversation.
Write to hello@wolf-tech.io or find us at wolf-tech.io.