Why wine data breaks generic software
Producer, vintage, appellation, format, provenance. Five fields that generic product models flatten into one — and what that costs downstream.
Ask a generic product database to store a bottle of wine and it will offer you a name, a SKU, a price and a quantity. Every one of those fields is a compression of something that matters commercially, and the compression is where the money leaks out.
A bottle is a relationship, not a row
Producer, estate, cuvée, vintage, appellation, classification, format, provenance, storage history, allocation rights, critic score, duty position. These are not tags on a product. They are related entities, and the relationships carry the value. Two bottles with the same label are different assets if one spent a decade in bond under climate control and the other travelled through three unrecorded owners.
Generic systems model this as variants: one product, several options. Variants assume the options are interchangeable in kind and differ only in a dimension the customer selects. Wine violates that assumption immediately. A 2010 and a 2011 are not sizes of the same thing. A magnum is not six times a 75cl in either price or scarcity.
Where the flattening shows up
The consequences arrive in three places, always in the same order. First in pricing: without vintage-aware comparables, thin-market wines sit at stale prices for years. Second in inventory: case-level counting cannot represent split cases, part-owned stock or bonded transfers, so reconciliation becomes a monthly manual ritual. Third in content: a catalogue built on flattened fields cannot generate accurate descriptions, because the accurate facts were never stored in the first place.
The alternative is unglamorous
The fix is not clever software. It is modelling wine identity properly — producer, cuvée, vintage, format — as the join key across every system, then attaching provenance and duty state to the bottle rather than to a spreadsheet beside it. Once identity resolves, the rest becomes ordinary engineering: pricing has comparables, inventory reconciles, content has facts to draw on.
That is the whole thesis behind Vinfra. Not a wine skin on retail software. A data model that starts from what makes a wine a wine, with the applications built on top of it.
Every workaround is a place where a human is doing the data model's job by hand.