When we pitch a stockist, the line that lands is: "You won't change a thing." No new software, no new process, no retraining staff. Keeping that promise is an engineering constraint, and it shapes how the connector is built.
Read-only by design
The connector never writes to the stockist's billing system. It reads. It pulls product masters, prices, HSN codes, GST rates, and stock quantities out of Tally / Marg / Busy and leaves the source untouched. There is no scenario where VeBy's software can corrupt or alter the books the stockist bills kiranas with. That guarantee is non-negotiable.
Meeting the software where it is
Indian FMCG runs on a handful of billing systems — Tally Prime dominates, with Marg and Busy close behind. Rather than ask stockists to migrate, the connector meets each one where it is: it extracts data through the export and integration surfaces these systems already expose, and normalises the differences between them on our side, not theirs.
Out of the way of billing
A stockist's busiest hours are when kiranas place orders. The connector syncs around that — lightweight, background, and tolerant of the machine being busy or briefly offline. It never sits between the stockist and their billing. If VeBy's sync is slow, the stockist's day is unaffected; the disruption budget is zero.
Why "passive" is the moat, not just a feature
Every stockist we add compounds the catalogue — but only because joining costs them nothing. A connector that demanded behaviour change would stall at the first busy week. Passive integration is what makes onboarding an entire association realistic, and it's why the data corpus can grow as fast as agreements get signed.