Here's a scenario most adult retailers will recognize, even if they've never quite admitted it. A customer calls one of our stores. “Hi, I placed an order on your website yesterday — can I change the shipping address?” The associate has no idea what the customer is talking about. There's no order in our system, and there's no record of the customer. The associate explains, awkwardly, that the website is run by a distributor and that the customer needs to call them. The customer is irritated — reasonably so. They thought they were doing business with us.
Now multiply that across every order placed, every cancellation request, every “Is my package coming today?” call, and every “Can I just pick this up at the store?” request we have to turn down because the order isn't connected to any of our locations. Multiply it by the walk-ins who showed up for products we don't carry, the order changes routed to the wrong company, and the return requests we couldn't help with. Each one is a small loss, but once you start looking, they're everywhere — and they add up faster than anyone wants to think about.
Your customers already think the website is yours — it’s time to make that true.
For a long time, that was just the cost of doing business. Most independent retailers couldn't afford to build, host and manage a real ecommerce site well, so we leaned on the distributor's site and accepted the friction. The friction was invisible enough — no one tracks the customer who quietly stops calling — that it was easy to underestimate.
That's why I started building our own site. It became the latest module on the platform I've been building to address the operational gaps left by our off-the-shelf tools. If you read last month's piece on accounting, this is the same philosophy applied to a different problem: identify where the friction is, then build something that actually removes it.
The Website Is the Store Now
Shopping has changed shape twice in my career. The first shift was the internet itself — customers could compare products and prices from their couch instead of driving to four stores on a Saturday. The second shift was subtler and matters more: customers stopped treating the website and the store as separate. They check the site before coming in. They expect what's online to match what's in the store. They expect to call the store about a web order and get answers. They expect to pick up an online order at the nearest location.
Your website is not competing with Amazon on price anymore. It is competing to inspire a trip to your store. And if your “website” is actually somebody else's website with your name on the wrapper, you're losing that competition every day in ways you'll never see on a Profit & Loss statement.
The fix is conceptually simple — host your own site, connect it to live POS inventory at every location, give stores visibility into web orders, and let customers pick up at whichever store has stock. The execution is where it gets interesting. The moment I started building, I ran straight into the problem nobody talks about: the products in our POS were sellable in the store, but they weren't sellable on the website.
Why 'Use AI to Write Product Descriptions' Misses the Point
Here’s what I found when I started populating the new site. Our full catalog includes about 60,000 products across all software providers and locations. At our flagship store alone, about 10,800 of those are in scope to appear on the website. Pulling them into a real ecommerce platform was the easy part — that’s a sync. The hard part was that what came through the sync was a SKU, a price, maybe a category. No long description. No dimensions. No weight. No materials. Often, there was no decent image, or the image looked like it had been screenshot from a 2009 catalog. Listed, but not actually sellable.
When people hear “AI for ecommerce,” they usually picture asking ChatGPT to write a product description. That's fine and works for a handful of products, but it's only a small part of the real problem.
The real problem isn't writing — it's plumbing. Every manufacturer ships product data in a different format. One sends a spreadsheet. Another sends an XML feed. Another sends a PDF sell sheet that you have to extract data from line by line. One has descriptions in one file and physical dimensions in a different file you didn't even know existed. Their image libraries are scattered across software providers' portals, file-share folders, and asset platforms — each with its own login, structure, and quirks.
Asking AI to “write a description” doesn't help when the bottleneck is that you have seven inconsistent data sources and no unified place to land them. The leverage isn't in the writing. It's in the normalization — taking whatever the manufacturer hands you and translating it into something your website can actually use.
That's the project I built.
How I'd Approach the Problem (Even If You're Not Going to Build It Yourself)
I want to walk through the thinking here because it's reusable even if the execution isn't. Whether you build something yourself, hire someone, or simply want to evaluate what a platform provider is selling you, the questions are the same.
Step 1: Define what “ready to sell” actually means. Before touching any tool, I wrote down the minimum requirements for a product to be enabled on the website — description, dimensions and at least one good image. Materials were a nice-to-have but not required. This sounds obvious, but it's the most-skipped step in every project like this. Without data requirements, you end up with a site full of half-finished listings and no way to tell which are which.
Step 2: Catalog where the data actually lives. Not where you wish it lived, not where the software provider's rep claims it lives — where it actually lives, provider by provider. Some providers are organized. Some have their assets in three different places. Some have great descriptions and no photos. Some have great photos and descriptions written by someone who has never used the product. Until you've completed this inventory, you can't plan the work.
Step 3: Build one normalizer per source, not a universal solution. The temptation is always to find one tool that ingests “everything.” But “everything” never works the same way twice. Accept that each software provider needs its own translation layer, and that those layers all output to the same standardized format your website understands. Build them once, then run them as often as you need.
Step 4: Gate publication on quality, not completion. A product shouldn't go live just because you have some data for it. It goes live when it meets the requirements you set in step one. A simple rule — “enable on the website only when the description, dimensions and images are all present” — prevents you from pushing half-baked listings to customers.
This is where AI earns its keep. Not by writing the descriptions, but by making the translation layer feasible to build in the first place. What used to take a developer a week per software provider now takes a developer a day because tools like Claude Code can read a software providers' feed format, understand its structure, and generate the normalization logic in a fraction of the time it would take to write by hand.
Build vs. Buy, Revisited
I keep coming back to this, and I'll return to it here. The off-the-shelf platforms are fine. For a single-location store with a few hundred SKUs, they're probably the right answer. But once you cross a certain threshold — multi-location, thousands of SKUs, multiple software providers' feeds — the gap between what those platforms do out of the box and what your business actually needs starts to widen. And the platforms aren't going to close it for you. They're built for the average customer. You are not the average customer.
Custom used to mean expensive and risky. Five years ago, this project meant hiring a development shop, scoping a six-month engagement, and crossing your fingers. Today, with the right approach and tools, it takes a fraction of the time and cost. The reason most retailers still don't do it isn't price — it's that they don't know it's possible or don't know where to start.
If you're losing sales to a website that you don’t run — or you're trying to figure out whether a platform company's pitch is real or marketing fluff — this is the kind of work I do, and the kind of conversation I'm always happy to have. The tools have changed, and so has the math on what is possible.
Much of the industry has yet to catch up, creating a valuable opportunity for retailers ready to take control. Your customers already assume the website is yours. Now it is time to make that true.
Zondre Watson is the general manager of technology and analytics for adult retail chain Ero-Tech. With a background in finance, chocolate and controlled chaos, he blends retail know-how with AI tools to keep 17,000 products moving smoothly.
