How AI Has Changed the Way We Build Products
27 September 2026
By Conor Doyle – Business Intelligence & Product Manager
A few years ago, building an internal technology product in ecommerce followed a fairly familiar process.
Someone spotted a problem, wrote a brief, joined the development queue and waited. The idea had to be scoped, prioritised and justified before much could happen. By the time something was built, the problem might already have changed.
That’s not really how we build anymore.
Over the past year I’ve worked on our Margin Optimiser, Image Optimiser and translation technology with AI involved at almost every stage. And I don’t mean using ChatGPT to write the odd bit of code. AI has become part of the process of designing, building, testing and debugging the product itself.
The obvious result is speed. But I don’t think that’s actually the biggest change. The bigger changes are who can build, how quickly an idea can evolve, and what becomes valuable when the actual act of building gets easier.
From an idea to a working product
Previously, if I had an idea for a new tool, I needed engineering resources to help build the Prood of Concept (POC.) That resource was limited and rightly focused on its own priorities, so an idea needed to be well thought through before anyone committed time to it.
That’s a sensible way to manage expensive development capacity. It also means you’re making quite a few decisions about a product before anyone has actually used it.
AI changes that.
I can now take a problem, build an initial version and put it in front of someone within days. If the idea doesn’t work, we know quickly. If it does, we can start building on it immediately.
The Image Optimiser is probably the best example. It started as a fairly simple question: how do a brand’s product images compare with the strongest listings in its category?
Once that worked, it raised another question. What about the rest of the listing? So we added titles, bullets, attributes and catalogue quality. Then A+ content. Then we started looking beyond Amazon.
As shoppers increasingly ask ChatGPT, Gemini and Perplexity what to buy, the next question became: how does a brand actually appear in those answers?
That original image tool has now evolved into something much broader around agentic commerce, bringing together marketplace content, webstore data and AI visibility. None of that was linked on a roadmap when the first version was built.
The product evolved because every working version showed us the next useful question. Tools that might previously have been independent now share data, scoring and functionality.
Under the old model, several of those steps could easily have become separate projects competing for development time. Now the product can move almost as quickly as the thinking does.
POCs have become much cheaper
This changes the economics of experimentation as well.
A proof of concept (POC) used to require development resource, budget and a place on the roadmap. That naturally meant prioritising ideas we already had a reasonable level of confidence in.
If you can build a POC in a few days, you can afford to test ideas you’re less sure about. That sounds like a small difference, but I think it’s one of the biggest benefits of AI-assisted development.
You don’t need to win the argument for an idea before you build it. You can build enough of it to find out whether the argument is worth having.
And showing someone a working product using their own data gets a much better reaction than showing them a slide describing what the product might eventually do.
That’s important. The combination of AI and our data means a POC doesn’t have to be an abstract demo. We can put a brand’s actual products, performance or marketplace data into it and see whether the idea works in the real world.
You find the problems earlier, you get better feedback, and changing direction is still cheap.
Custom technology becomes much more realistic
Speed is the obvious benefit, but there’s another one I think is more important for ecommerce.
We can build for the problem in front of us, rather than the average problem.
Most off-the-shelf ecommerce software has to work for thousands of customers. It solves the common problems very well, but if your business works slightly differently, you usually adapt your process to the software.
AI-assisted development starts to flip that around.
The brands we work with operate across different marketplaces, regions and D2C webstores. They have different catalogue structures, pricing rules, content standards and ways of working. Previously, building around all those differences could become expensive very quickly.
Now a brand-specific pricing rule, a new scoring method or a report designed around how one team actually works can often be built and tested in days.
Our translation work is a good example. Generic translation isn’t particularly difficult anymore. But translating product content while preserving a brand’s tone of voice, terminology and style across multiple marketplaces is a much more interesting problem.
That’s where custom technology becomes valuable. Instead of asking the brand to fit the software, you can increasingly shape the software around the brand.
But faster doesn’t mean easier
There is a catch to all of this. AI makes it very easy to build something that looks finished.
That is not the same thing as building something that works properly.
A lot of my time now goes into deciding what is worth building next, defining the rules the product has to follow, and checking what was actually built rather than what the AI tells me it built.
AI-generated code is usually confident. It’s neatly structured, it explains what it has done and, most of the time, it works.
Which is exactly why the mistakes can be dangerous.
The Margin Optimiser taught us that quickly
Our Margin Optimiser automatically makes pricing decisions within rules we define. That means a mistake isn’t just something wrong on a dashboard. It can affect a live price.
We found one particularly good example around Amazon pricing data. When there were no competing offers, Amazon could return a value that ultimately appeared as zero. The system was treating that zero as a genuine price signal.
Nothing crashed. There was no big red error message.
The system was working exactly as instructed. The problem was that the instruction was based on the wrong interpretation of the data.
We’ve seen the same issue elsewhere. A score that couldn’t be calculated appeared as 0 out of 100. To a user, “we couldn’t measure this” and “you scored zero” mean completely different things. To a computer, unless you explicitly tell it otherwise, they can look identical.
That experience led to one of the simplest principles we now use: missing means missing.
If we don’t have the data, the product says that. It doesn’t invent a value, assume zero or quietly fill the gap.
The model isn’t the advantage
For all the attention AI gets, you can’t do very much in ecommerce without good data.
You can give two businesses access to the same AI model and the same development tools, but if one has years of clean product, pricing, sales, traffic, advertising and marketplace data and the other doesn’t, they are starting from very different places.
AI doesn’t remove that advantage. It makes it more valuable because we can now do more with the data we already have.
Our Margin Optimiser only works because it can combine live marketplace signals with the pricing rules and guardrails we hold for each product. Our agentic commerce work becomes much more useful when we can connect what AI assistants are saying about a product with the underlying listing, content and performance data.
Even something like translation becomes more valuable when it sits alongside the product catalogue, brand guidelines and existing content instead of working from a blank prompt.
The AI model itself isn’t the differentiator in any of those examples. The value comes from combining the model with data that is relevant, structured and understood.
And that last word matters. Having a lot of data isn’t enough. You need to know what it means.
A product built in a week on poor data is still a poor product. You’ve just reached the wrong answer faster.
That’s why another principle we’ve learned is simple: test with real data as early as possible.
Clean test samples behave beautifully. Real ecommerce data doesn’t. Products have missing attributes, feeds arrive differently, marketplaces interpret fields in different ways and APIs don’t always return what you expect.
Every time we’ve put real client data through a POC, we’ve found something a clean test sample would never have shown us.
In ecommerce that gets complicated quickly. Data can come from Amazon, other marketplaces, advertising platforms, D2C webstores and internal systems. The same metric can mean slightly different things depending on the source. Sometimes data is delayed. Sometimes it’s missing. Sometimes an API simply doesn’t provide the thing you want.
So the questions before a build haven’t disappeared. Where does the data come from? How complete is it? What does it actually represent? What happens when it’s missing? How do we know when it’s wrong?
If anything, those questions matter more because the build itself has become so easy.
AI might be changing how we build the machinery, but the quality of what comes out still depends on the raw material going in.
So where does engineering fit?
AI hasn’t removed the need for engineers. If anything, I think it lets us use engineering resource better.
Instead of asking an engineering team to spend weeks proving whether an idea has value, we can get much further with the POC first. Once something proves useful, engineering becomes critical for hardening it, securing it, integrating it properly and making sure it can scale.
They’re working on something people have already used and already want.
That’s a much better starting point.
The bigger change
So far, a lot of the conversation around AI development has focused on doing existing things faster. Building a POC in days rather than months is an obvious example.
But I think the more interesting change comes when we stop using AI simply to speed up the old process and start changing the process around what is now possible.
We’re starting to see that in product development.
The barrier between the person who understands the problem and the person who can build the solution is getting much smaller.
The best knowledge in an ecommerce business doesn’t only sit with developers. It sits with account managers who know why a particular Amazon listing behaves strangely. It sits with marketplace specialists who know where the data is unreliable. It sits with people managing brands every day who know which edge cases actually matter.
Until now, most of that knowledge reached technology second-hand through a brief, ticket or feature request. AI lets those people get much closer to the build itself.
And increasingly, that means they can build too.
One of the things I’m most interested in now is helping people across the business learn how to turn an idea into a POC themselves. They don’t need to become developers. They need enough of an understanding to take a problem they know well, give it some structure and build something that can be tested.
That changes where innovation can come from.
If the person closest to a problem can prototype an idea, test it with real data and show whether it has value before engineering gets involved, that’s not just the old development process moving faster. It’s a different way of developing products.
Instead of a small number of people deciding what should be built for the rest of the business, someone working directly with a brand can spot a problem on Monday and have the beginnings of a solution by the end of the week.
Most of those ideas won’t become full products, and they shouldn’t. But lowering the cost of trying them means more good ideas get the chance to prove themselves.
For me, that’s where this gets particularly interesting. AI isn’t just making product development faster. It is giving more people across the organisation the ability to participate in it.
The role of a central product or innovation team changes too. It becomes less about owning every idea and more about giving people the tools, data, guardrails and support to experiment safely, while recognising which POCs are worth turning into proper products.
That doesn’t mean everyone suddenly becomes a software engineer. It means more people can turn their expertise into something tangible, test it and work alongside engineering to take the best ideas further.
And this is where I think the real advantage starts to become clearer.
The AI models will become widely available. The ability to build with them will become increasingly common.
What won’t be identical is the knowledge inside a business and the data it’s built up over years.
That’s the combination that matters.
AI has made building easier. Our people know what is worth building. Our data gives those products something valuable to work with.
Put all three together and you have a much more powerful engine for innovation.