Retail & Ecommerce Software

Retail software has one hard problem and a lot of easy ones dressed up to look hard. The hard one is knowing, at this moment, how many of a thing you have and where it is. Everything else — the storefront, the recommendations, the loyalty programme — is downstream of that, and none of it survives being wrong about it.

Inventory is a distributed systems problem wearing an apron

The moment you sell in more than one place — a website, a marketplace, three stores, a quick commerce partner, now ONDC — you have a distributed inventory problem, and the classic failure is selling the same last unit on two channels within the same minute.

The fix is not "sync more often". It is to hold a single source of truth for available-to-promise, model reservations explicitly with a TTL, and never let a channel hold stock it has not reserved. A marketplace that pulls your feed every fifteen minutes must be given a deliberately conservative buffer, because it is going to oversell you otherwise and the penalty lands on your seller rating, not theirs. Store stock has to be counted, and cycle counting has to be built into the software as a routine rather than treated as an annual event that everybody dreads.

ONDC is a protocol, not a marketplace, and that changes what you build

Teams keep approaching the Open Network for Digital Commerce as though it were another Amazon to list on. It is not. It is a set of protocol specifications you implement as a seller app or a buyer app, and the network then routes between participants who have never heard of you.

The consequences are concrete. Your catalogue has to map to the network's taxonomy, and the mapping is genuinely tedious and genuinely important. Order state transitions follow the protocol's lifecycle, not yours. Cancellation, return and issue-and-grievance flows are specified, and you must implement them properly — including the ones you would rather not. Settlement is reconciled against the network, not against a single counterparty you can telephone. It is real work, and it is worth doing for the reach, but it is not a listing exercise and anyone selling it to you as one has not built it.

Marketplace settlements are where the margin actually goes

Amazon and Flipkart do not pay you what the customer paid. They pay you the customer's payment, minus a commission, minus a closing fee, minus shipping, minus whatever they have decided to deduct this week — as a lump sum covering hundreds of orders, arriving on their schedule.

If your finance team is reconciling this in Excel, they are not reconciling it. They are checking the total looks plausible and moving on, and the deductions nobody validated are pure margin leakage. We build settlement ingestion that parses the report, matches every line to an order, recomputes what the deduction should have been against your commission agreement, and raises a discrepancy queue when it does not match. The recovered amounts routinely pay for the module inside a year.

The rest, briefly

Returns are 20 to 30 percent of fashion GMV and the reverse logistics workflow deserves as much design as the forward one. GST across states with correct place-of-supply and HSN codes. Store billing that keeps working when the internet does not, syncing when it returns. And a product catalogue with real attribute modelling, because a catalogue that cannot express variants properly will hobble every channel you ever connect to it.