Soissons Belles — antiques inventory engine
Designing a product system from spreadsheets to storefront
This project started with a straightforward request: build a website for a new antiques dealer.
Like many early-stage businesses, their inventory lived in Excel. It was the fastest way to get started, easy to update, and flexible enough to capture notes, prices, dimensions, and descriptions as stock came in. For a new operation, this was practical rather than careless.
The problem emerged when the business wanted to present the collection publicly. The spreadsheet worked for internal reference, but it wasn’t designed to power a website. Information was inconsistent, fields were overloaded with multiple meanings, and the same object could be described in different ways depending on who entered it.
The task was not to “design a nicer front end.” It was to design a system that could turn a fragile spreadsheet into a reliable product foundation, without forcing the business into a generic e-commerce model that didn’t fit how antiques are bought and sold.
Role: Senior Product Designer
Scope: Product strategy, systems design, data modelling, UX, frontend development
Deliverables: Inventory engine, admin workflow, public catalogue website
I was responsible for defining the problem, designing the system, and implementing the first version end to end.
Antiques behave very differently from standard products. Every item is unique. Descriptions are nuanced. Prices are often contextual. Sales happen through conversation, not checkout.
Most commerce platforms assume the opposite. They expect fixed prices, consistent attributes, and high-volume transactions. Using one would have solved the technical problem quickly, but at the cost of distorting the business itself.
The spreadsheet, on the other hand, was flexible but unsafe. It mixed facts with assumptions, editorial text with structured data, and left too much open to interpretation.
The challenge was to replace the spreadsheet without losing flexibility, while creating enough structure to support a website and future growth.
My initial approach was pragmatic. Instead of asking the client to manually restructure their data, I built a small import and enrichment pipeline in mjs that could take the Excel export and prepare it for use in a content system.
The script normalised categories, attempted to infer missing fields, generated slugs and titles, and generally tried to “clean up” the data automatically. From a technical standpoint, it worked well. The output looked coherent and complete.
From a product standpoint, it was a mistake.
The enrichment created a false sense of confidence. Items appeared finished, but some of the inferred data was subtly wrong. Periods were guessed. Materials were over-specified. Ambiguity was replaced with certainty where none existed.
In antiques, this is dangerous. Missing information is acceptable. Incorrect information is not.
At that point, I stopped pushing the system further in that direction.
The failure wasn’t technical. It was conceptual.
I had optimised for completeness instead of trust.
Rather than asking how much the system could infer, I reframed the problem around what the system should explicitly refuse to do. The goal became to surface uncertainty clearly instead of hiding it behind automation.
This meant accepting that not everything could or should be enriched automatically.
I rewrote the import process around a set of quality gates.
The mjs pipeline still handled ingestion and basic normalisation, but it stopped short of guessing. Required fields had to be explicitly confirmed. Certain attributes were allowed to remain empty until verified. Editorial descriptions were clearly separated from factual metadata.
Items moved through clear states, from incomplete to review-ready to publishable. Nothing could appear on the website simply because it existed in the spreadsheet.
This shifted responsibility back to where it belonged. The system enforced structure and consistency. The client provided expertise and judgment.
The spreadsheet became a raw input format, not a hidden dependency.
With quality constraints in place, I designed a content model that reflected how antiques are actually documented and evaluated.
Each item needed to support structured facts such as dimensions, origin, period, and materials, alongside richer editorial content like provenance and condition context. It also needed to reflect reality over time, including availability, holds, and sales.
This model was designed before any interface work began. By resolving the information architecture first, I avoided building UI that had to compensate for unstable or ambiguous data.
The inventory engine became the backbone of the product. Everything else depended on it.
For administration, I avoided building custom tools prematurely. Instead, I shaped the data model to work cleanly within an existing content environment, giving the client a focused and calm way to manage inventory without introducing unnecessary complexity.
Only once the system was stable did I design the public-facing catalogue. Because the underlying data was disciplined, the front end could be deliberately restrained. There are no e-commerce tropes, no artificial urgency, and no interface elements competing with the objects themselves.
Each item page is powered directly by the inventory engine. What the client manages is exactly what the public sees.
The result is a custom inventory system that replaces spreadsheets with a structured, scalable foundation, without forcing the business into a model that doesn’t fit.
Data quality is higher. Errors are surfaced early rather than hidden. Updates are faster and safer. The website feels considered and trustworthy because it is built on something solid.
Just as importantly, the system can evolve without being rebuilt. New inventory, richer content, and future workflows can be added without rethinking the core architecture.
This project is a good example of how I approach product problems.
The most valuable work wasn’t visual design or technical implementation. It was recognising when a solution that “worked” was still wrong, stopping early, and redesigning the system around trust rather than automation.
Good products aren’t built by making systems smarter. They’re built by deciding where intelligence should live, and where constraints matter more than convenience.
That’s the kind of work I enjoy doing, and the kind of problems I’m hired to solve.