Our Customer Built a Boardroom (C-Suite) Dashboard in an Afternoon. We Didn't Write a Line of Code.

Walk across almost any university campus or town park and you'll find them: muddy tracks worn into the grass, cutting the corner the architect assumed you'd walk around. Planners call them desire paths. They're the routes people actually take, as opposed to the routes someone decided they should take.

Software has always been built like the paved paths. The vendor decides where the routes go, the users follow them, and if you want a new one you file a request and wait for the council to send a man with a wheelbarrow.

Today a customer walked straight across the grass. 🌿

The meeting that went off-script 🎬

It was a routine weekly review with one of our clients, a US home furnishings brand. I'd joined specifically to demonstrate our new MCP server. I had the demo ready. I had my talking points ready.

Before I could share my screen, their senior application developer told me he'd already connected it. Then he showed me what he'd built with it.

Their product and design teams had asked for a way to see every product in an upcoming launch on one screen. They wanted to see where each product sat in development, how complete its data was, and which items had been cancelled. That view was going to be presented to the boardroom, or C-suite as our American friends call it. It's the kind of request that normally lands on a vendor's roadmap as a "new feature" and waits its turn.

Instead, he opened Claude chat, connected it to our MCP server and described what he wanted. A few hours later he had a working dashboard:

You type in a launch tag and it pulls in every matching product, live from the PIM.
Each product shows its development status and its completion percentage.
A filter strips out cancelled items.
The whole thing is shared as a link with the people who need it.

He hadn't used Claude Code or written any integration. He did it in a chat window, in an afternoon.

And here's what makes it more than a pretty report: it was reading live data. This wasn't a spreadsheet export frozen at nine o'clock this morning. While we were talking, their product team was busy in the PIM updating statuses, filling in attributes and adding images, and the dashboard reflected every change the moment it was made. A completion score ticked up as someone finished a product; a cancelled item disappeared as soon as its status changed. ⚡

Anyone who has ever presented a launch review knows the familiar feeling of the numbers on the slide already being out of date by the time the meeting starts. This dashboard can't go stale, because it doesn't keep a copy. It asks the PIM every time.

My honest reaction was: "If you showed this to somebody, they'd think you'd spent months building an app." His was even better. He said he was impressed with what Claude could do, given that he'd started out knowing nothing about it.

Why this matters more than it looks 🔍

It would be easy to file this under "neat AI trick". I think it's something bigger.

For thirty years, the PIM has been a place you go to. You log in, you navigate, you export to a spreadsheet, and you do the real thinking somewhere else. The vendor decides what views exist. If you want a new one, you raise a ticket and hope.

MCP flips that. The PIM becomes a place your AI goes for you. The question stops being "does the software have a screen for this?" and becomes "can you describe what you want?"

And this customer isn't alone. Since we switched the MCP server on, we've seen:

A retailer asking Claude to compare the product data in their PIM with what's live on their website, and list the differences. It found the errors on the site in minutes.
A manufacturer uploading their sales figures and asking which best-sellers had the weakest product information. A few top sellers turned out to be missing data altogether.

None of these needed an export, a spreadsheet or a development ticket, and none of them was working from yesterday's data. 📊

During the meeting he also mentioned that two other vendors of theirs have switched on MCP in the past fortnight. The tide is coming in quickly.

The interface that didn't exist until someone asked 🪄

Here's the part that genuinely stopped me in my tracks. I've been in technology for forty years. When I was doing my PhD in expert systems in the late 1980s, the user interface was a green screen and a blinking cursor. I'd assumed what I was looking at today was still years away.

Dynamic UI, created on demand.

For my entire career, every piece of software has worked the same way. Designers sit in a room and guess what users will need. They build the screens, ship them, and then everyone (users included) adapts to those screens. If your question doesn't fit a screen that already exists, tough luck. You export to Excel.

What I watched today turned that upside down. Nobody designed that dashboard in advance. No UX team ran workshops and no product manager wrote a spec. It came into existence because a product team had a question, and it was shaped exactly around that question: this launch, these statuses, this completion score, cancelled items hidden.

It's the difference between buying a suit off the peg and walking into a Savile Row tailor, except the tailor finishes before you've had your tea. 🧵

That changes what a PIM vendor's job is. We no longer have to predict every screen every customer might ever want. Our job is to make sure the data underneath is clean, structured and trustworthy, and that the door to it is secure. The interface becomes something your AI assembles when you need it, for as long as you need it.

These are desire paths for software. Some will be walked once, for one meeting, and then grow back over, and that's fine. But the ones people keep walking deserve paving, which brings me to what's next.

Read-only is just the opening chapter 📖

At the moment our MCP server is read-only. It can see attributes, families and product data, and that alone is surprisingly powerful, as you've just seen.

Where we're heading is what I'd call a headless PIM: everything you can do inside OneTimePIM, your AI can do from outside it. That means creating and editing agent tasks, adjusting the Python behind them, setting up imports and exports, and building designs.

When one of those paths gets walked often enough, it's time to pave it. That's what the Apps feature is for. 🛤️

OneTimePIM can run custom Apps inside the PIM: one click from the menu, available to the whole team, no artifact links to pass around. If you want something permanent, we build it into an App for you, using Claude Code and the same calls the MCP already uses. The dashboard that started as a one-off experiment becomes part of your PIM.

The next step is to cut out the middleman, which is us. Once the MCP can build Apps as well as read data, you'll be able to tell your AI "make this permanent" and then open the PIM to find it waiting for you.

Fast, but not reckless 🔐

There's a reason we started with read-only. An AI that can change product data is enormously useful, and an AI that corrupts product data at machine speed is enormously not.

So every new capability we open up through the MCP will follow the same rules:

Your permissions. It works through your user account, so it can never do more than you could do yourself.
Your channels. It only touches the channels you've scoped it to.
Fully traceable. Every change it makes is logged against a real user, exactly as if you'd made it by hand.

Slowly and securely beats quickly and regrettably.

Pave where people walk 🌿

The smartest planners don't fight desire paths. They wait, watch where people actually go, and then pave those routes. The park ends up shaped by the people who use it, not by a guess made in an office years earlier.

That's the model I believe in for PIM. Give customers good data and an open door, and they'll show you the routes they need, often before your demo has finished loading. Then pave the best ones.

Our job as a PIM vendor has quietly changed. We're still the specialists who plan your data model, keep it clean, and support you without limits. But we're also building the foundation your own AI builds on. The customers who see that first are already a few months ahead of everyone else.

If you'd like to see what Claude can do with your product data, book a call with me. Bring a question you've never had a screen for.

Frequently asked questions

What is an MCP server? MCP (Model Context Protocol) is an open standard that lets AI assistants like Claude connect securely to external systems. OneTimePIM's MCP server lets an AI read your product data directly, with no exports needed.

Do I need to be a developer to use it? No. The dashboard in this story was built in Claude's ordinary chat interface, not in a coding tool.

Can the AI change my product data? Not yet. The MCP server is currently read-only. Write capabilities will arrive gradually, always working through your user permissions and channels, with every change traceable.

What can I use it for today? Cross-referencing PIM data against your website, spreadsheets or sales reports; building reporting views and dashboards; and answering questions about your catalogue in plain English.