Every growing Amazon agency eventually hits the same fork: as clients multiply and reporting gets heavier, do you build your analytics and infrastructure in-house or buy a turnkey platform? In 2026, the question feels different, because AI has made building deceptively easy. On an episode of MerchantSpring Marketplace Masters, John Aspinall, Chief Evangelist and Creative Director at Velocity Sellers with two decades across agencies and software, worked through the decision honestly.
The tell, Aspinall says, is what happens in daily operations when something breaks: how much does it cost to fix yourself in the short term versus buying a solution that just works? Plenty of agencies run a patch, a Band-Aid, because they don't yet have the client base to justify turnkey but can't keep limping along either. He puts rough numbers on it. At ten to fifteen clients, a manual Google Sheet with imports is perfectly fine. At twenty, twenty-five, thirty, you have to start asking what the long-term answer is, and the real question underneath is where you are going: fifty clients, or two hundred?
That makes it a founder's strategic decision, not a technical one. If the plan is to reach two hundred or five hundred clients, a home-built stack that keeps breaking is just Band-Aid after Band-Aid, when what you need is to, in his phrase, go to the doctor and get it fixed. Notably, plenty of capable agencies could build it; Aspinall has worked at firms with hundreds of clients that absolutely had the engineering chops, but chose not to, because it wasn't the best use of the effort. And some founders genuinely don't want to scale; boutique at fifteen or twenty clients is a legitimate sweet spot. The trap is drifting toward two hundred clients on infrastructure designed for twenty, because at scale you have the revenue but also have to deliver, or, as he puts it, it's churn city.
Aspinall is no Luddite; he demoed his own setup live, an agentic coding environment wired into Claude Code with custom scripts, and his Google Workspace connected so a single command can send a calendar invite, a follow-up email and a summary doc. His point was precisely that in 2026 you can build almost anything, which is exactly why the discipline has to come from somewhere else.
His rule of thumb: if you don't know how to do the task the tool is doing, you are hyper-dependent on the tool. Scale on a PPC platform without understanding PPC, and when that software gets absorbed, hikes its price, or an API breaks, the client won't accept “my software broke.” They will say you're the expert; fix it. So for the first ten clients, he argues for mastering the unglamorous fundamentals, even a plain spreadsheet, before layering on systems, because if you buy a solution before you understand the work, you won't know what to do when it fails.
The flip side is just as important: Velocity uses MerchantSpring's APIs to pull data into its own internal tools, but the team understands reporting fundamentals, so if the platform ever disappeared, they wouldn't be left scrambling. Understanding your own operation is what lets you safely adopt tools, in either direction.
The trap most founders fall into is mistaking the visible layer for the whole job. AI makes it trivial to spin up a beautiful dashboard in a weekend, the same way agencies once wired a data source into Looker Studio and marvelled at how good it looked. But the visualisation was never the hard part. The hard part is everything underneath: API authorisations, keeping pipelines refreshed, and handling the fact that marketplace data isn't static; an order from three weeks ago can be updated, so you have to keep re-checking. One client with a couple of API calls is easy. A hundred clients across twenty different APIs, consistently, with error handling, is a different sport.
Aspinall is blunt about why. An API key isn't a finished integration; behind it sit dozens of endpoints and long documentation, and you have to know exactly which endpoint returns the data you want. Stitch several APIs together, and the failure modes multiply: one goes down, another times out or hits a rate limit, and suddenly a brand manager is stuck on a client call because the report won't generate.
And when Amazon changes a single piece of its reporting, a home-built stack can break overnight, sending you scrambling to find the one thing that changed, whereas a mature platform has already planned for it. His image is hard to forget: you can vibe-code a CRM that laps HubSpot visually, but without the boring operational bones, the error handling and the bug-fixing nobody wants to own, you've got a Ferrari with no engine sitting in the driveway. This is the layer where agencies most often decide to buy (MerchantSpring's data layer is built specifically to solve it).
A common argument for building is that off-the-shelf analytics is a commodity: if two hundred agencies use the same dashboards, where's the edge? Aspinall's answer is a car analogy. New entrants arrive cheaper and flashier every year, but they don't outsell Toyota or Ford, because a large share of buyers want reliability over novelty; they don't want to wonder whether the thing will work while they're driving.
The raw number is commoditised, he concedes: if you sold a thousand dollars on Amazon, every tool reports a thousand dollars. What isn't commoditised is reliability, custom solutions, white-labelling, backup and the size and focus of the team behind the tool. “We're three people who vibe-coded this, and we're figuring it out” is not a reassuring answer when a client's revenue rides on it.
The stakes scale with the client. A boutique serving newer sellers can absorb the ebbs and flows of switching tools. Land a Procter & Gamble, though, and the relationship inverts: enterprise clients dictate exactly how they need their data and reporting, expect it on the hour every time, and run a multi-step process to vet whether you can slot into their operations.
You think you're vetting the client; they're vetting you harder, and they will not change their inner workings to fit yours. Deviating from what you promised, Aspinall warns, puts your own recurring revenue at risk. He sums the failure mode up as penny-wise, dollar foolish, though he's equally clear you don't need the most expensive option, just the one that genuinely fits.
Some agencies spend heavily, occasionally millions, building internally before deciding to walk away, and Aspinall draws a sharp line between two versions of that moment. When someone who genuinely understands the work, say a real PPC expert, builds a tool and then concludes it costs too much, that is a hard but educated call: the same money put into marketing, sales, and outbound would have generated more clients and revenue than the half-finished tool. When someone who doesn't understand the work built it only to avoid paying, they aren't making a calculated pivot; they're scrambling out of necessity, switching because they can't even run the process themselves.
The distinction matters because it changes your negotiating position. An agency that made a clear-eyed decision keeps leverage; one that panicked and now needs any solution has none, and, as Aspinall notes wryly, software vendors know a forced buyer when they see one. Sunk cost, in other words, is only a trap if you let the money you've already spent, rather than the honest read of where the work goes from here, drive the next decision.
None of this makes Aspinall anti-AI; he's pointed about where it pays off. His own project is replicating images across an image stack at scale, a genuine enterprise pain point. Consumer-grade AI image tools handle one-offs, but a brand with three thousand ASINs and twenty colour variations needs everything brand-consistent and compliant with legal and marketing guidelines, not cool visuals that drift from listing to listing.
His approach pairs Claude Code with an image model, feeds it a reference and the instruction to change nothing, and scales a designer's definition of “what good looks like” across hundreds of ASINs. The value is obvious: large-catalogue brands almost always have under-optimised listings simply because there are too many variations to fix by hand, and the manual ROI never adds up.
The principle generalises into a simple filter for agencies: find the repetitive, painful, valuable process and automate that. Aspinall cites industry figure Ritu Java's rule: if her team does the same thing more than three times, it gets automated, which is a pragmatic test for what deserves engineering effort. It is also the same logic that governs the whole build-versus-buy question. Spend your scarce building energy on the differentiated work only you can do, and buy the reliable, undifferentiated infrastructure that simply has to work every time.
If the data pipeline is the part you'd rather not babysit at scale, that's the case for buying it. MerchantSpring is the reporting layer more than 300 agencies rely on across 120-plus marketplaces, with white-labelled, client-ready reports and open APIs so your team can still build on top, the exact setup Aspinall's does. Agencies report saving several hours per account manager each week. See how agencies use MerchantSpring, or book a walkthrough of your own client accounts.