01 · Live store · Full-stack
Telling shoppers “fits” only when the data says so
Every page now reads one compatibility result with three states, so a gap in the data no longer shows up as a promise.
This store sells parts that only work with certain models, so every page has to answer one question: will this work with what I own? A blank field used to mean “fits all”, and each page type worked out the answer on its own.
Full reasoning: constraints, options, verification and cost
What made it hard
- Much of the compatibility data is incomplete, and “unknown” was not a value it could hold.
- The answer is needed on model pages, product pages, a sizing guide and a bundle builder.
- One model can come in several configurations.
- Shoppers who haven't chosen a model still have to be able to buy.
Options
Keep “fits / doesn't fit”Not chosen
Simple, but missing data still reads as a promise, and that becomes returns and complaints.
Patch each page separatelyNot chosen
Fastest for one page, but the same model and product can get different answers across the site.
One shared result: fits, conditional or unknownChosen
Pages display the result and never guess. Unverified never renders as “fits”, and a conditional result asks the shopper one more question.
What shipped
- A shared compatibility result used across model, product, guide and bundle pages.
- Conditional results ask one or two follow-up questions, the most decisive first.
- Single-product purchase is never blocked without a chosen model. The check is offered instead.
How it was checked
- Each release went through several rounds of pull-request review and preview checks on representative models.
- Ambiguous data rows went to the operations team instead of being resolved in code.
What it costs
- Models without reviewed statuses have to stay out of the new behaviour until their data is done.
- Three states add a loading and “still checking” case to every purchase path.