Fashion retail analytics from size-level stock data
We were engaged to build TIYO, which showed buyers what sold out, how fast and in which sizes.
The market and the problem
Fashion retailers publish size-level stock availability on every product page, and nobody was storing it as a time series. We engineered the machine that turns changes in that availability into a demand signal buyers can use: crawlers, an event store, analytics and the products on top.
Fashion buying is a bet placed months ahead. Size ratios are committed the better part of a year before a garment reaches the shop floor, mostly on last season's numbers and instinct. The industry pays for the misses: Bloomberg Intelligence put discarded inventory at $163 billion a year back in 2022, and sizes are where much of it goes wrong.
The intelligence market splits into two camps. Trade press costs a few hundred pounds a year and tells you stories. Enterprise platforms cost tens of thousands and tell you what competitors have in stock. Neither tells a mid-market buyer the thing they most want to know, which is what left the shelf, how fast, and in which sizes.
That gap was the starting point of the brief. Availability data is public. Sold-out states are public. If you record them often enough, the difference between two snapshots is a sales signal no survey can match.
What we built
We delivered the platform behind five products on one data spine: a cross-retailer discovery feed for buyers, analytics views, a field-scouting tool, reports, and an enterprise merchandise-planning module. All of it stands on the crawl.
The data engine
Twenty-two retailer crawlers, polling product and size availability through the day across 13 markets.
Competitor stock and sell-through by size
The main view: every product's sizes across time, so a buyer can see exactly which ones sold out and how fast. Sell-out velocity is the closest thing to competitor sales data that exists outside their boardrooms.
Fashion retail analytics that answer buyer questions
Speed, price, assortment, discounting and new-in views across retailers and countries, built for comparisons like 'how deep is their outerwear range in Germany versus ours'.
Boards for buying meetings
Buyers filter the cross-retailer feed, shortlist items, and collect them into boards for a buying meeting. Price histories and size availability travel with every item.
Scouting from the field
A capture tool for store visits: photos with location and price metadata, grouped into collections the wider team can vote on through a share link, without needing an account.
Enterprise merchandise planning
A module built with a major multi-brand retail group, ingesting their ERP data and computing size-level buy proposals from real sell-rates. The size-level approach was proven on actual enterprise sales data before it went anywhere near a wider market.
The engineering
Most of the hard problems here are about durability: data that keeps flowing when a retailer redesigns its site, and a history that can be recomputed whenever the analysis improves.
TIYO's data engine in outline. Crawlers read structured product data, and every observation is appended to an event store on Bigtable and never overwritten. The searchable copy in Elasticsearch is built from it, and one .NET backend serves the products. The front end reaches the backend through its own small server. It is hosted on GKE. Highlighted: the event store, so that whenever the analysis improves it can be rerun across years of history.
Crawlers that read structured data
Coverage is the product, so the data has to keep arriving whatever the retailers change. The crawlers read structured product data rather than page layouts, so a retailer's redesign does not break them.
An append-only event store
Whenever the analysis improves, it can be rerun across years of history. Every observation is appended to an event store on Bigtable, keyed by product, and never overwritten; the current view and the searchable copy in Elasticsearch are built from it. A design that updated records in place would have made that impossible.
Making 22 retailers comparable
Buyers can compare like with like across retailers and countries. Hundreds of retailer-specific category names collapse into a short list of common categories, and each product keeps one identity across countries and currencies. Unglamorous work, and precisely what turns 22 feeds into one answerable question.
A backend built for many products
Five products run on the same data, and each user sees only what their role allows. One .NET backend serves all five, and the React front end reaches it through its own small server, so the API is never exposed to the internet directly.
Built to keep running for years
Keeping a data platform running and changing for years is a different job from building it once. TIYO was built and evolved over several years by a small team. The current phase rebuilds the engine lean on PostgreSQL and containers, ready for its next product.
Where AI fits
Fashion is racing into AI, and mostly using it to write product descriptions. The problems worth paying for sit deeper in the data, and TIYO's next phase is built around them. Computer vision already tags product images in the pipeline, and the rest of the roadmap is specified and costed.
One TIYO roadmap item: its metrics drive a drafting pipeline of observation, interpretation and action, with a human editor on top. Highlighted: the drafted narrative.
- Iron mark: where the human editor reviews.
Tag garments from product images
Retailer product data says 'dress, £49'. It never says oversized, wide-leg or quiet luxury. A vision model extracting a 16-attribute profile from every product image, joined to sell-out velocity, answers the buyer's real question: which combinations of silhouette, colour and fabric are selling out fastest right now.
Predict sell-through from the first 48 hours
The event store already holds every product's full availability curve, which means training labels cost nothing and regenerate with every crawl. A model reading early size-depletion patterns can flag likely sell-outs before anyone decides on a markdown.
Let models draft the narrative
The heaviest cost in any intelligence product is the writing. TIYO's metrics can drive a drafting pipeline (observation, interpretation, action) with a human editor on top. The economics of the whole reporting product swing on this one workflow.
Catch retailer site changes the same day
With a crawl configuration for every retailer and country, a changed data format somewhere is a weekly certainty, and the cost of keeping up grows with coverage. A model that compares a changed response with the last good one can name the fields that moved the same day, so a retailer's redesign is caught before the data goes stale.
Phases, team and price
Delivery record
- Status
- In build, re-platforming for a subscription product
- Earlier phases
- In production for years
- Programme
- Several years, in four phases
- Team
- Engineers across phases
Case study published , updated .
The TIYO engagement has run as a phased programme across several years, with the team scaling as each product proved itself. Programmes like this sit at the top of the build bands we publish.
Four phases, in the order listed below. Highlighted: phase 2, the data engine, which built the data asset the rest depends on.
Indicative price
£350k to £550k across the programme
Data platforms of this scope, a crawl engine, an event-sourced store, analytics and multiple product surfaces, typically run £350,000 to £550,000 cumulatively over two to three years with a small senior team. Excludes infrastructure costs, at London rates as of mid-2026. Bands describe the shape of the engagement, not a specific invoice.
The band in this study's price note, on one linear scale from zero. It is a band for the shape, not an invoice.
- 1. Cumulatively over two to three years: £350,000 to £550,000
How we build
What every build goes through
These commitments hold on every build we run:
- Nothing is built until the specification is written down and you have agreed it.
- A senior engineer reviews every change before it is merged.
- Automated tests run on every change, and a failing build does not ship.
The delivery record shows this project's own details. How we work sets out the rest of the method.
What the engagement achieved
TIYO ran in production for years, served a listed retail group's merchandise planning, and gave the client a data asset that would be hard to recreate: multi-year, size-level availability history across the European high street.
The current phase is the interesting one. The engine is being repackaged behind a subscription intelligence product, with the AI extraction pipeline as its lead feature. The data survived every change of direction, which is rather the point of building it as an event store.
- 22 retailer integrations across 13 countries, polled through the day
- Size-level sell-out history stored as an append-only event stream
- Five products served from one data spine
- Enterprise module validated against a listed retail group's real sales data
Five products served from one data spine, all of it standing on the crawl: a cross-retailer discovery feed, analytics views, a field-scouting tool, reports and an enterprise merchandise-planning module. Highlighted: the data spine.
The decision we would defend
History is append-only
Every observation goes into an event store on Bigtable and stays there, and the current view and the searchable copy are built from it. Whenever the analysis improves, it can be rerun across years of history. A design that updated records in place would have made that impossible.
Planning something like this?
Indicative price
£350k to £550k across the programme
A band for the shape, not an invoice.
The first step
Specification sprint
£4,500 or £8,500One to two weeks
The written specification, architecture, estimate and risks: one week for a single workflow, two for a platform. You can take it to any supplier, us included.
Asked about this project
What is TIYO?
We were engaged to build TIYO, a fashion retail-intelligence platform. It tracked product and size-level stock availability across 22 high-street retailers in 13 countries, polling through the day, and converted the changes into demand signals: what sold out, how fast, in which sizes and markets. The engine is now being re-platformed.
What did Quantum Craft build for TIYO?
The full platform across several phases: the retailer crawl engine, an event-sourced data store on Bigtable with Elasticsearch projections, a CQRS .NET backend, the React buyer application, a field-scouting tool, and an enterprise merchandise-planning module that ingests ERP data and computes size-level buy proposals.
How did TIYO differ from tools like WGSN or EDITED?
Enterprise platforms are strong on what competitors stock and what trends forecast. TIYO was built to show what left the shelf: because it recorded size availability as a time series, it could show sell-out speed per size per market, which assortment snapshots cannot.
1 more question
What does a data platform like TIYO cost to build?
Programmes of this shape typically run £350,000 to £550,000 cumulatively over two to three years with a small senior team, excluding infrastructure. A first usable phase, one data source through to one analytics surface, lands well under that.
Tell us what you're building or deciding.
Tell us about a product you want built, or a decision about AI you need to make, and we'll set up a 30-minute call. You'll get a straight answer on what it would take.
What happens after you get in touch
We reply within one working day
By email, to arrange a time for the call.
A free 30-minute call
With a senior engineer, about what you are building or deciding.
The fee in writing first
If a first step is worth taking, you get its exact fee in writing before any work starts.