CatalogXpert

CatalogXpert is an AI sales assistant for stores that sell technical products, where it is easy to buy parts that do not work together. A store adds it to its site with one script tag. It talks with shoppers, builds them a complete setup from the store’s own catalog, and checks that the parts fit. It was founded in March 2026 as a venture between JDW Ventures and my company, Gamache Technology Solutions, and I am a co-founder. I wrote the original demo and the first sales engine, and the specs the platform was built from.

Visit catalogxpert.com All projects

Role Co-founder
Venture JDW Ventures and Gamache Technology Solutions
Founded March 2026
Work Original demo · First engine · Build specs
Platform Since May 2026
First category Audio and AV, in a pilot
Stack Python · FastAPI · Postgres · Chroma · Claude

A drawing of how CatalogXpert fits together: a retailer’s site adds the chat widget with one script tag; the public widget gateway checks the key and the site and streams the reply; each tenant has its own private sales engine; the engine reaches everything through the private internal API, which sets the tenant from the engine’s token and scopes each call to PostgreSQL with Row-Level Security, the tenant’s Chroma collections and Claude, with the cost of each call recorded; the operators’ dashboard reads the same data

A drawing of how the pieces fit together, not a screenshot.

What it is

A shopper tells the assistant what they are trying to do, usually with a budget. It asks what it still needs to know, recommends products from that store’s catalog, and puts the whole setup together, down to the wire and connectors people tend to forget. One button adds all of it to the cart.

Underneath is a platform built to host many stores at once. Each store gets its own sales engine, and each store’s conversations, carts and product data are kept apart from every other store’s. The first engine sells audio and AV, and as of September 2026 one pilot is running in that category. The public site lists HVAC, plumbing and industrial as the categories that come next.

I wrote the original demo, which ran on its own before there was a platform, and the sales engine inside it, which became CatalogXpert’s first engine. In May 2026 it was moved onto the platform, where it reaches the database, the product data and the model only through the internal API. You can try it on the live demo.

Process

How it was built

I wrote two specs. The platform’s build spec went in with the repository’s first files and set the architecture: a platform shared by every store, a separate sales engine for each one, engines that never touch the database or hold an LLM key, and the path a message takes from the widget to the model. It also set the order of the build and said to check each step before starting the next. The second spec covered moving the original demo onto the platform as its first engine.

Much of the implementation against those specs was done by AI coding agents working in parallel on their own branches, and I reviewed the work before it was merged into main. Every push to main runs the same checks: linting, strict type checks on the platform code, and the tests, apart from the end-to-end ones, against real PostgreSQL and Chroma databases.

Timeline

How it came together

March 2026

The venture

Founded

CatalogXpert was founded as a venture between JDW Ventures and my company, Gamache Technology Solutions, to build an AI sales assistant for technical catalogs.
March to May 2026

The original demo

Before the platform

After the venture was founded I wrote the original demo, a standalone version of the sales assistant, and its sales engine, the one that builds complete audio and AV systems.
May 9, 2026

The foundation

The first day

The build spec I wrote went in with the first commit, alongside the repository’s skeleton. By the end of that day the platform was in place: the database with its tenant isolation, sign-in, the private internal API and the SDK engines use to call it, the dashboard’s back end, the public widget gateway, the connection to Claude, and the tenant isolation tests. Moving the sales engine I had written for the original demo onto the platform, under my migration spec, began the same day, and by that night it was connected to all of it end to end.
May 2026

The main build

Most of the work

The dashboard went in the next day, with admin pages for managing tenants and an audit log. Over the month each store got its own model setup, with a main provider and an optional backup, and a way to invite users with a one-time link. The widget gained one-click swap cards and a live view of each reply as it is written, and stores could choose which sites may embed it. Each slot in a bundle started accepting only the kinds of product that belong in it. At the end of May the first version of the public site went in.
June 2026

A QA pass

Simulated shoppers

On June 2 a QA pass sent simulated shoppers with different needs and budgets through the demo. Tracing the failures it reported turned up real problems: a plain request like “speakers for my living room” did not start a bundle, some ways of writing a budget were missed, and the assistant asked again for things a shopper had already told it. Fixes for all three went in on June 3. Store details such as the support contact also moved out of the shared prompt into settings each store controls from the dashboard.
September 2026

The public site

catalogxpert.com

The site got its privacy policy, terms and AI disclosure pages, analytics, and a blog with its own editor. I added an MCP server so an AI agent can draft, edit, publish and illustrate blog posts. The widget’s script tag now loads a tiny bootstrap, which pulls in the rest of the loader from a minified file that browsers can keep in their cache.

Capabilities

What it does

01 · Plans

It plans the whole setup

The engine keeps a plan for each conversation: slots such as the front speakers, the amplifier, the subwoofer, the wire and the connectors. Each slot accepts only certain kinds of product, so a self-powered speaker cannot fill a slot meant for speakers run from the shopper’s own amplifier.

02 · Checks

Checked after the model answers

A checking pass after each reply catches picks that do not fit the plan and swaps them out. Rule-based filters drop products the specs rule out, such as a power supply with the wrong voltage, current or AC/DC output for the amplifier.

03 · Widget

One script tag

The chat has a cart, links for sharing a cart, and a voice mode. While a reply is being written, a shopper can open a live view of it. Swap cards show the price difference for each alternative and replace an item in one click.

04 · Dashboard

A dashboard for each store

It shows stats on sessions, carts and abandonment, and every conversation with its transcript and what its LLM calls cost. A store copies its embed code there, sets the sites allowed to use it, invites users with a one-time link, and sets its model and support contact. Platform admins also get pages for tenants and an audit log.

05 · Site

catalogxpert.com

The public site is a small FastAPI app with Jinja templates, kept separate from the platform. It has structured data for search engines, a sitemap and RSS feed, a demo request form, and a Markdown blog edited through Decap CMS. It runs the widget with the same script tag a store would use.

06 · MCP

A blog an agent can write

An MCP server on the site lets an AI agent draft, edit, publish and illustrate blog posts. Every save goes through the code that renders the blog and is checked against the house style. New posts start as drafts, and deleting anything is left to a person.

Architecture

How it is built

The widget is plain JavaScript. The script tag adds a small launcher, and the chat itself runs in a frame, apart from the store’s own page.
The widget gateway is the only public way in for shoppers. It checks each request’s key, checks that the page embedding the widget is one the store allowed, rate-limits it, and streams the engine’s reply back over server-sent events.
Each store has its own sales engine, a separate Python service with the conversation logic. Engines reach the database, the vectors and the model only through the platform’s SDK.
The internal API is private. It works out the tenant from the engine’s token, so an engine never sends a tenant ID, and a request for another tenant’s data gets a 404, as if it did not exist.
PostgreSQL with Row-Level Security holds the tenant data. The tenant is set at the start of every transaction. Conversations, messages and events are split into monthly partitions, and a background worker creates the coming months ahead of time.
Chroma holds each tenant’s products, content and FAQs in collections of its own.
Every LLM call goes through the internal API, which holds each store’s model keys encrypted, can fall back from the main provider to a backup, and writes the tokens and cost of each call onto the conversation.
Sign-in uses Argon2 password hashing and sessions kept on the server so they can be revoked, and it supports two-factor codes. API keys and engine tokens are stored only as hashes and shown once, when they are created.
A tenant isolation test suite runs against a real database and checks that one tenant’s engine cannot reach another tenant’s conversations, carts, plans, shared carts or vectors.