I built a product catalog tool for shop owners who can't code

August 24, 2026 · second post

Status check, up front: what follows is a real prototype I built, not a client success story. No shop has signed up yet at the time of writing. I'll say clearly in a future post whether that changes.

The problem I noticed is small and specific: a lot of local shops (I was looking at furniture and handmade-accessory shops) already have a website, but the products themselves aren't really on it. There's a homepage, maybe an Instagram link, but no page where you can actually see what they sell, one item at a time, with a price.

That's not a technology problem in the usual sense — the shop owner isn't going to learn to code, and they shouldn't have to. So instead of pitching "I'll build you a website," I built two working demos first, using a made-up example shop, so an owner could see exactly what they'd be getting before agreeing to anything.

Two versions, because "one size fits all" was wrong

I built two different prototypes, aimed at two different kinds of shops:

A general goods shop version ("Yui"): one single page that works as both the public catalog and the owner's own editing screen. Good fit for a shop with a lot of items that change often — the owner needs to add, edit, or remove products quickly, without touching two separate files.
A furniture/craft workshop version ("fushi"): the public catalog page and the owner's update tool are two separate files. The update tool has its own live preview panel that reflects edits instantly — but, as of this build, it doesn't push those changes to the separate public catalog file automatically. That's a real limitation, not a design choice, and it's next on the list to fix. This version puts more weight on material and size — the kind of detail that actually matters when you're deciding whether a chair will fit your room.

Both save data in the browser (localStorage) rather than needing a real backend or database, which kept the whole thing to plain HTML files — no server to set up, no hosting bill, nothing that could break in a way I couldn't debug myself.

What building it with an AI assistant actually looked like

This wasn't "describe an app, get an app." A few concrete things happened along the way:

The first version of the photo gallery had an icon-overlap bug that only showed up once real product photos (not placeholder emoji) were dropped in — caught and fixed during a review pass, not on the first try.
I initially assumed one catalog design would work for both shop types. It didn't: the "everything on one page" approach that suited a shop with lots of fast-changing inventory felt wrong for a furniture workshop, where a customer needs to slow down and look at material and dimensions. That's why there are two versions instead of one.
Not everything carried over between the two versions on purpose — a "sold out, see similar items" link made sense for the general-goods version (lots of similar items to redirect to) but wasn't implemented the same way on the workshop version, because that catalog doesn't have the same kind of category browsing.

Where this actually stands

Both prototypes work, and sales materials (a before/after comparison, a rough pricing hypothesis) exist to show real shop owners. What hasn't happened yet, as of this post, is a confirmed client — that part depends on actually walking into shops and having the conversation, not on the code. I'd rather report that honestly than skip ahead to a result I don't have yet.

If you're trying something similar — building a real tool before you have a real client, to make the pitch concrete instead of abstract — I think that order (prototype first, sales conversation second) was the right call. It gave me something to actually show instead of describing an idea. It's the same order I used for the pricing tool for makers: build the working thing first, then figure out who actually wants it.

This project is also one of the three I mention in a later post about letting AI subagents make the day-to-day decisions across everything I'm building — including the honest fact that, as of that post, this one still doesn't have a signed client either.

Frequently asked questions

Has a shop actually signed up to use this?

No, not yet. As the status note at the top of this post says, this is a real working prototype, not a client success story. No shop had signed up at the time of writing.

What's the difference between the "Yui" and "fushi" versions?

"Yui" is a single page that acts as both the public catalog and the owner's editing screen, built for a general goods shop with a lot of items that change often. "fushi" is aimed at furniture and craft workshops and splits the public catalog and the owner's update tool into two separate files, with more weight on material and size details.

Does the "fushi" version sync updates to the public catalog automatically?

Its update tool has a live preview panel that reflects edits instantly, but as of this build it doesn't push those changes to the separate public catalog file automatically. That's a real limitation, not a design choice, and it's next on the list to fix.

Why use localStorage instead of a real database?

Both prototypes save data in the browser (localStorage) rather than needing a real backend. That kept the whole thing to plain HTML files — no server to set up, no hosting bill, nothing that could break in a way I couldn't debug myself.

Is this tool for sale right now?

Sales materials (a before/after comparison and a rough pricing hypothesis) exist to show real shop owners, but that part depends on actually walking into shops and having the conversation — it isn't something you can buy off this site today.