Answer in brief
A product price names a defined unit; a service estimate prices a proposed path to an outcome. Comparing the two requires separating inventory risk, production repeatability and returns from discovery, labour, revisions and client dependencies.
Two catalogues, one company, two different objects
VITON13 publishes two things that behave like catalogues. The store lists garments and accessories across four brands. VIT MARKET lists digital services — websites, SEO and content, automation, and applied AI. On screen they rhyme almost exactly: an eyebrow category, a title, a short description, a price, a button. A visitor moving from one to the other would be forgiven for thinking they were browsing the same kind of thing.
They are not. Counted field by field, the two catalogues share almost no structure. One is built out of units that can run out; the other is built out of bands of time that cannot. Everything downstream — how a price is written, whether there is a photograph, whether you can order it on the site — follows from that single difference.
Here is the method before the numbers. The product side is recomputed for this article from the store's own modules, read through the marketplace layer that normalises them into one feed. The service side is counted from the services module, with the price aggregates quoted from VJOURNAL's first-party dataset, which publishes its own arithmetic: the floor and ceiling of each band are read verbatim, the midpoint is their arithmetic mean, and no currency conversion is applied anywhere.
The census: 29 fixed numbers against 100 ranges
The store's priced side is 29 listings: 16 Old Money pieces, 10 VITON13 & RISE pieces, 3 ANIRI pieces. Each publishes one number. Not a single one publishes a range. Their floor is $34, their median $290, their ceiling $1,890, and their total sticker value $9,690.
The services catalogue is 100 listings, evenly split at 25 per group, and every one of them is priced. Ninety-nine publish a band rather than a point — exactly one service has a floor identical to its ceiling. Add the floors and you get $43,690. Add the ceilings and you get $156,330. Add the midpoints and you get $100,010.
The midpoint distribution runs: minimum $32.50, first quartile $366.25, median $750, third quartile $1,333.50, maximum $5,009.50, mean $1,000.10. The lowest floor anywhere in the catalogue is $15; the highest ceiling is $10,000.
Put the two ceilings side by side and the asymmetry is easy to see. The most expensive object in the entire store, a tailored suit at $1,890, is worth more than three quarters of the service catalogue's midpoints — it sits above the $1,333.50 third quartile — and yet it is only 18.90 per cent of the single largest service ceiling. The store's summit is the services catalogue's upper-middle.
Ten times the money from three and a half times the listings
The services catalogue carries $100,010 of midpoint value against the store's $9,690 of sticker value. That is 10.32 times the money. It does it with 100 listings against 29, which is 3.45 times the listings. Per listing, the two averages are $1,000.10 and $334.14 — a ratio of 2.99.
The medians land closer than the totals suggest: $750 against $290, a factor of 2.59. Most of the gap between 2.59 and 10.32 is the tail. A service catalogue can put a $10,000 line item next to a $50 one without anybody blinking; a store cannot, because a garment's price is anchored to a physical object.
The tallest numbers make the same point. The services catalogue's highest published ceiling is $10,000. The store's most expensive object is $1,890. Those are 5.29 times apart, and only one of them is a promise rather than a thing.
The floors invert it completely. The cheapest listing in the services catalogue starts at $15. The cheapest thing in the store is a pair of shorts at $34. The catalogue that contains a five-figure line item also contains the cheaper of the two entry points, because a store's floor is set by what an object costs to make and a service catalogue's floor is set by how small a task the company is willing to name.
A picture sells a garment; a sentence sells a service
The 29 store listings carry 121 product images between them — an average of 4.17 each, split 76 for Old Money's 16 pieces, 32 for RISE's 10 and 13 for ANIRI's 3. The 100 service listings carry zero. This is not a missing asset or an empty placeholder: the service record has no image field of any kind. Its keys are a number, a title, a difficulty label, a category, a description, a rouble price string, a dollar price string, a duration, a slug, a group, two numeric dollar bounds and a featured flag. Photography was never part of the schema.
The words take up some of the slack. Service descriptions average 29.22 words, with a median of 28.5 and a range from 18 to 42, for 2,922 words in total. Product descriptions, as the marketplace layer normalises them, average 21.07 words, median 21, range 16 to 29, for 611 in total. The services catalogue carries 4.78 times the description text across 3.45 times the listings.
That is the honest division of labour between the two. A garment is sold by showing what it looks like; a service is sold by describing what will exist when it is finished. One catalogue's production cost is a photo studio and the other's is a writer, which is also why the two cannot be maintained by the same workflow no matter how similar the cards look.
Inventory is a number; capacity is a duration
Every one of the 29 store listings carries at least one size, 129 options in total. No service carries a size. Every one of the 100 services carries a duration. No store listing carries one. Between those two sentences sits the whole difference between selling a thing and selling work.
Stock is where it gets concrete. Nineteen of the 29 store listings declare a stock integer: 245 units in total, worth $108,125 at sticker, of which 219 units and $104,470 belong to Old Money. The remaining ten — the entire RISE drop — declare no stock field at all. On the services side there is no equivalent field anywhere. Nothing in the module records how many of a service can run at once.
The services catalogue does carry a field the store has no analogue for: all 100 listings are labelled with one of three difficulty levels. The nearest thing a garment has is a care instruction, which all 29 listings publish. One catalogue grades the buyer's project; the other grades nothing and tells you how to wash it.
This is the real distinction, and it is not cosmetic. A store listing is a countable unit that can run out and therefore has to be counted. A service listing is a commitment of time that cannot run out but can be over-promised — and the catalogue records the first kind of scarcity in an integer while leaving the second unrecorded entirely.
The one-line filter that decides which brands reach the marketplace
The two catalogues do meet in one place. The marketplace's product layer reads Old Money, RISE and ANIRI, normalises their three different record shapes into one, and links each resulting card back to the canonical store page instead of creating a second copy of the product inside the market. That last decision is deliberate and stated in the module: two URLs for one product is a duplicate content problem, not a feature.
The layer applies one filter before anything reaches the feed: keep only records whose dollar price is greater than zero. VITON13 BEAUTIE's six fragrances have no price field at all, so they never enter. The marketplace therefore presents 29 products from three brands while the store hub presents four collections. A single comparison operator is doing the work of an editorial decision.
Normalisation also flattens vocabulary in ways worth noticing. The merged product feed carries 14 distinct category labels across 29 products, or 0.48 labels per listing. The services catalogue carries 82 distinct categories across 100 listings, or 0.82 — it is close to naming a category per service. And merging exposes collisions: Trousers, with four Old Money items, and Pants, with two RISE items, sit in the same feed as separate categories for the same garment type.
Three of the 29 products carry a category that no brand ever wrote. ANIRI's records have no category field, so the normaliser substitutes its own fallback string, Statement, and that word appears on exactly the three ANIRI cards. It is a small thing, but it is the clearest illustration of what a merge layer does: where a source is silent, something has to speak, and what speaks is code.
Two very different ways to say yes
A service can be ordered on the site. The service detail page submits a request and returns the visitor a private request URL under the market's secure-request route, so the transaction has an identifier before a human has said anything. There is a dedicated test in the suite covering that flow, which is a reasonable proxy for how load-bearing it is.
A product cannot. The store keeps three separate bags in three separate browser-storage keys — one for Old Money, one for ANIRI, one for RISE — and the shared cart route reads only the first of the three. Its own English copy invites you to review sizes, colours and quantities "before the future checkout layer is connected". The store is, by its own description, pre-checkout.
That makes one of the store hub's hero claims half true. It prints one shared account and bag system. The account half holds: the ANIRI module imports its current-user function from the Old Money module, so both brands read the same VITON ID record. The bag half does not: there are three keys, and the RISE bag never touches the account at all. Counted honestly, the store has one account and three bags.
What neither catalogue can tell you
Neither one contains a completed transaction. There is no order table, no signed brief, no invoice, no lead outcome. The $9,690 and the $100,010 are both what the company is asking for. What anyone paid is not in either dataset, and no amount of re-slicing these fields will produce it.
The $100,010 is not even an asking price, strictly speaking. It is the sum of the midpoints of 100 bands, computed by a stated method. The identical catalogue supports a $43,690 reading if you take every floor and a $156,330 reading if you take every ceiling, and neither is more honest than the other. Where a real quote lands inside its band is a negotiation this data does not observe.
The stock figures are declared, not measured. They are integers in static data modules, not readings from a warehouse system, and ten of the 29 listings omit the field entirely — which is a gap in the record and not a claim that the shelf is empty.
Most importantly, nothing here says which catalogue matters more to the business. Ten times the sticker value is not ten times the revenue. A $9,690 catalogue selling repeatedly can out-earn a $100,010 one selling rarely, or fail to, and these two price lists cannot distinguish those worlds. Comparing catalogues tells you what a company has built. It does not tell you what a company sells.
Decision framework: selling products versus services
A product price names a defined unit; a service estimate prices a proposed path to an outcome. Comparing the two requires separating inventory risk, production repeatability and returns from discovery, labour, revisions and client dependencies.
The fixed product shelf can show a final price because the object already has a specification. A service range narrows only when inputs, decisions, acceptance and operating conditions become equally explicit.
Use one comparison sheet for products and another for services: record unit, ownership and return terms on the first; scope, assumptions, milestones, acceptance and change control on the second.
Practical checklist
- selling products versus services: write the promised outcome and acceptance rule.
- selling products versus services: record every exclusion, dependency and unresolved assumption.
- selling products versus services: assign an owner and review date to evidence that can narrow the estimate.
- Use one comparison sheet for products and another for services: record unit, ownership and return terms on the first; scope, assumptions, milestones, acceptance and change control on the second.
Questions and answers
selling products versus services: what should a buyer verify first?
A product price names a defined unit; a service estimate prices a proposed path to an outcome. Comparing the two requires separating inventory risk, production repeatability and returns from discovery, labour, revisions and client dependencies. Use one comparison sheet for products and another for services: record unit, ownership and return terms on the first; scope, assumptions, milestones, acceptance and change control on the second.
selling products versus services: which assumption changes the estimate most?
The fixed product shelf can show a final price because the object already has a specification. A service range narrows only when inputs, decisions, acceptance and operating conditions become equally explicit.
selling products versus services: what is the next practical step?
Use one comparison sheet for products and another for services: record unit, ownership and return terms on the first; scope, assumptions, milestones, acceptance and change control on the second.

