The subscription bill is visible. The cost of replacing it usually arrives later.

A working prototype makes the argument tempting. Your team can see the dashboard, ask questions of the data and imagine several monthly subscriptions disappearing.

Then someone asks why yesterday’s numbers have changed. A connection fails. The person who built it goes on holiday. What looked like a saving starts competing with client delivery for time.

None of that means agencies should avoid building software. It means the reason to build needs to survive contact with the responsibility of owning it.

Through ELEVATE, I’m interested in how agency owners turn their expertise into a business that can deliver consistently as it grows. Software belongs in that discussion because it can make an agency’s methods repeatable, or give a stretched team another operation to maintain.

For this edition, James Northcott, CEO and founder of Toucan, and Rich Morris, co-founder of Push-Pull, explain what they have chosen to build. Scott Needham, CEO and founder of SmartScout, and Andrew Hamada, CEO and co-founder of Reason Automation, bring the perspective of people who have spent years building software and supplying the data behind it.

Together, they make a stronger case for choosing carefully than for taking either side of a build-versus-buy debate.

What does your agency need to do its own way?

James starts with a useful warning:

“I think agencies need to be very careful not to confuse being able to build software with actually having a reason to.”

Toucan’s motivation comes from the way its team makes decisions.

Specialist providers solve valuable problems in advertising, reporting, profitability and analytics. But a commercial decision often depends on how those areas interact, alongside the brand’s circumstances and the agency’s experience.

James wanted to embed Toucan’s methodologies and processes into technology, rather than continually adapt the agency’s approach to fit someone else’s software.

That still leaves room for third-party tools. His contribution explicitly recognises their value, as well as the maintenance and development responsibilities that come with building.

The distinction matters. “We can recreate this feature” is a different investment case from “we need our own way of bringing information together and deciding what happens next”.

For an agency owner, the second deserves closer attention.

It also needs an honest answer: can you explain the method clearly enough for someone else to use it? Software will struggle to make an advantage repeatable if that advantage still exists mainly in the founder’s head.

Own the connections that matter

Rich describes a deliberately selective approach at Push-Pull.

The agency brings client-authorised Amazon data into one warehouse alongside its forecasts, listing content and task system. It buys project management software, language models and specialist tools.

Its own development focuses on connecting evidence to action.

Rich gives a practical example: the advertising budget an account manager sees comes from the same forecast used by the automated rules that control spend. Approved listing copy has a single source of truth, with records of what was submitted and checks before the team tells a client a change is live.

The point is consistency between what the agency knows, what it recommends and what it actually does.

His principle is clear:

“Build only what lets you show a client the evidence behind a decision, and buy everything else.”

That is Push-Pull’s chosen boundary, rather than a universal prescription. But it forces a useful question: which part of your proposed build changes the quality or reliability of client delivery?

A dashboard can look distinctive while leaving the underlying decisions exactly as they were.

Before building the tool, understand its inputs

Andrew brings the discussion underneath the interface.

When Reason Automation started, he wanted to create insight systems and management platforms for Amazon. Reliable access to Vendor Central data proved to be a more immediate problem. The pipelines built to address it became the company’s primary product for years.

His warning is that reliable data is an easily underestimated part of the job.

It is not enough to know which reports a tool needs. You also need to know the level of detail, the historical coverage, how often the information should refresh and how close to real time users expect it to be.

Then come storage, security and access.

Rich’s experience reinforces the point. He says Push-Pull spends more effort on data freshness, caveats and approvals than on charts. Settlement delays, currencies and different feeds affect whether a number can be trusted.

For an agency, that creates an obligation to explain what its software is showing.

If a client challenges a recommendation, can the team establish which data was available, what period it covered and which assumptions shaped the answer?

A polished interface does not answer those questions for you.

Buying can be a deliberate advantage

Scott’s contribution is a useful counterweight to the enthusiasm for building.

He recognises that substantial subscription costs can justify investigating an internal alternative. He also stresses that every tool needs maintenance as the environment around it changes.

His other point is particularly relevant to agencies: competitor and market intelligence can involve data that is harder to obtain than the information in a client’s own account. Acquiring it may carry separate collection or API costs.

Recreating the screen does not necessarily recreate the information behind it.

Scott therefore sees a combination of approaches: specialist market intelligence bought from providers, agency-specific reporting built around existing capabilities, and a mixture elsewhere.

That gives agency owners a more useful comparison than subscription price versus the cost of the initial build.

What does the subscription actually provide? Data access? Specialist expertise? Updates? Support? What would the agency need to take responsibility for if it stopped paying?

Buying those capabilities can leave the team free to build something more valuable around them.

Decide what you want to own before deciding what to build

My view is that an agency’s software should follow its commercial model.

If your value depends on combining client knowledge, commercial constraints and your own methods, there may be a strong reason to build around that combination. Especially where important context sits outside Amazon’s account data: margins, cash requirements, stock commitments, wider marketing activity and the reasoning behind previous decisions.

But owning code is not the same as owning an advantage.

The advantage needs to show up in the work: a better decision, a more reliable process, less avoidable rework or a result the client values. It also needs someone accountable for keeping the system useful.

Before replacing a subscription, I would want to see the full cost of operating the alternative, including the work the team will have to stop doing to support it.

And before commissioning an internal platform, I would want the owner to finish this sentence:

“We need to own this capability because it allows our agency to…”

If the answer is only “save the subscription”, the comparison needs more work.

If it explains how the agency’s knowledge becomes better, more consistent decisions for clients, there may be something worth building.

With thanks to James Northcott, Rich Morris, Scott Needham and Andrew Hamada for their contributions.

Get the monthly ELEVATE roundup

For ELEVATE’s take on the month’s themes, original commentary and Amazon agency M&A coverage, you can also receive our monthly email roundup. This is separate from subscribing to the weekly LinkedIn newsletter.

Subscribe to the monthly email roundup. Please confirm your subscription using the email sent after signing up.

ELEVATE | Strategic advisory for Amazon agency owners Start-Up → Scale-Up → Sale