The demand signal hiding in plain sight
Fashion retailers publish size-level stock availability on every product page, and nobody was storing it as a time series. TIYO polls it through the day, and the deltas between polls show what actually sold, in which sizes, in which country. We engineered the machine that makes that signal usable: crawlers, event store, analytics and the products on top.
The market, and the problem worth solving
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 actually want to know, which is what left the shelf, how fast, and in which sizes.
That gap is the founding observation behind TIYO. 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
TIYO is five products on one data spine: a cross-retailer discovery feed for buyers, analytics views, a field-scouting tool, curated reports, and an enterprise merchandise-planning module. All of it stands on the crawl.
The data engine
Twenty-two retailer crawlers driven by 138 per-country configurations, polling product and size availability through the day across 13 markets. The crawlers speak to the same APIs the retailers' own mobile apps use, which is far more durable than scraping web pages.
The size and time matrix
The signature view: every product's sizes across time, showing exactly which ones sold out and how fast. Sell-out velocity is the closest thing to competitor sales data that exists outside their boardrooms.
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'.
From feed to buying meeting
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, no account needed.
Enterprise merchandise planning
A module built with a major multi-brand retail group, ingesting 22 entity types from their ERP and computing size-level buy proposals from real sell-rates. The size-intelligence thesis was proven on actual enterprise sales data before it went anywhere near a wider market.
The engineering
The hard problems here are all about durability: keeping the data flowing, keeping identities stable across 22 retailers, and keeping history recomputable as the models improve.
Crawling the durable way
Every spider reads structured JSON from retailer mobile APIs rather than fragile page markup. Getting there takes real reverse engineering, and staying there took purpose-built token infrastructure to satisfy modern bot defences. Coverage is the product, so resilience is the job.
An event-sourced product history
Every observation appends to a Bigtable event store keyed by SKU, then folds into current state and projects into Elasticsearch for querying. Because raw events are never overwritten, history can be recomputed whenever the analytics improve. A mutable design would have made that impossible.
Making 22 retailers comparable
Five hundred and nineteen retailer-specific category names collapse into 17 normalised buckets, and products get stable identities across countries and currencies. Unglamorous work, and precisely what turns 22 feeds into one answerable question.
A backend built for many products
A CQRS .NET backend with 136 feature slices behind 153 endpoints serves five distinct products from one data spine, with nine user roles gating access. The React front end talks to it through a Node BFF, so the API is never exposed to the internet directly.
A programme, not a sprint
Around 96,000 lines of application code across four services, built and evolved over multiple years by a small team, with 12 contributors across its life. The current phase strips the engine down to PostgreSQL and containers, ready for its next product.
AI with a job to do
Fashion is racing into AI, and mostly using it to write product descriptions. The valuable problems sit deeper in the data, and TIYO's next phase is built around them. Computer vision is already in the pipeline, auto-tagging product imagery, and the roadmap ahead is specified and costed rather than aspirational.
See garments the way buyers do
Retailer APIs say 'dress, £49'. They never say 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 question buyers actually ask: 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 the markdown decision, turning description into forecast.
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.
Crawlers that heal themselves
With 138 crawl configurations, API drift is a weekly certainty, and adaptation cost scales with coverage. An LLM agent that diffs a changed response, proposes the field-mapping fix and opens a pull request turns maintenance from a tax into a background process.
Shape, effort and money
TIYO has run as a phased programme across several years, with the team scaling between two and four engineers as each product proved itself.
Indicative investment
£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 team of two to four. Excludes VAT, proxy and infrastructure costs, at London rates as of mid-2026. Bands describe the shape of the engagement, not a specific invoice.
Where it landed
TIYO ran in production for years, served a listed retail group's merchandise planning, and built a data asset nobody else in its niche holds: 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 sharpest edge. The data survived every pivot, which is rather the point of building it as an event store.
Asked about this project
TIYO is a fashion retail-intelligence platform. It tracks product and size-level stock availability across 22 high-street retailers in 13 countries, polling through the day, and converts the changes into demand signals: what sold out, how fast, in which sizes and markets.
Ready to build the thing?
Book a free 30-minute call. We'll dig into your idea, your stack and your timeline, and give you an honest read on what it will take to build and launch. You'll leave with a clearer plan whether or not you hire us.