How Hiyield built a bug-fixing machine with Marker.io

The challenge:

Two words: email chaos. Before Marker.io, QA relied entirely on clients firing over emails when something wasn't working. What arrived was almost always some variation of "the button doesn't work." Which button? Which page? What browser? What were they doing first?

“Before Marker.io, we'd hand a client the product and ask them to email us with any issues. What came back was always vague - no context, no detail, just 'this doesn't work.' We'd spend more time figuring out what the problem was than actually fixing it" - Jamie Curnow, Principal Web App Developer 

The PM (Project Manager) would dig in, ask follow-up questions, go back and forth, and eventually scrape together enough detail to write a ClickUp ticket. Then a developer would investigate, replicate the issue, spin up a local environment, fix it, and relay the outcome back. Via email. Again.

It worked. In the same way that sending a fax works. Technically fine. Absolutely nobody's first choice.

The solution 

Marker.io actually found Hiyield first.

The team had been getting serious use out of Marker's AI features when an email landed - would they want early access to a new MCP server? James Ellis (Delivery Manager) clocked immediately that it could plug straight into the AI agent workflows the team were already building with Claude, and pinged Jamie Curnow and Ben Short (Co-founder & Senior Developer). What started as "ooh, interesting" turned into something much more exciting very quickly.

The upgrade from email to Marker.io was already a proper game-changer. Clients could click directly on the broken thing, and Marker would instantly capture the browser, the URL, the console state, and everything that led up to the issue. No more back and forth. No more "can you send a screenshot?" The context was just... there.

"The difference is night and day. Instead of a back-and-forth trying to pin down what a client means, we get a Marker report with everything - the page, the browser, the exact element. We can just get on with it." - Jamie Curnow

The ClickUp automation made it even smoother - Marker issues flow straight into tasks, skipping the manual ticket creation step entirely.

But the real magic came when the team started playing with Marker.io's MCP server.

Here's what they built: a client logs an issue in Marker.io, and the automation fires. A ClickUp ticket is created. An AI coding agent picks it up - and instead of a developer manually trawling through Marker for context, the agent queries the MCP server directly. It pulls the screenshot, the console errors, the network requests, everything it needs. Then it attempts a fix and raises a PR. Automatically.

A human developer reviews the PR. Job done.

To make it work, Hiyield needed Marker.io to support a different kind of authentication - one that would work in the background rather than just through the desktop app. So they emailed and asked.

"We needed a different type of authentication to make our workflow possible, so we reached out to the Marker.io team. They came back the next day with something ready to test. For a request like that, that turnaround was pretty remarkable." - Jamie Curnow

Next. Day. Often, feature requests with external companies disappear into the void, so this felt like something worth talking about.

Getting everything wired up took a bit of back and forth - particularly around getting the AI agent to correctly read instructions embedded in ClickUp tasks. Ben worked through the kinks in conversation with Claude, tracking down why the agent kept ignoring certain fields and nailing the fix.

"You can watch the agent work through it in real time - calling the MCP server, pulling the screenshot, checking console errors, reviewing network requests. It's building up a picture of the issue the same way a developer would, just in seconds.." - Ben Short, Co-founder & Senior Developer 

‍

The results 

The end-to-end flow works. A bug lands in Marker.io. The automation fires. The AI agent queries the MCP server, grabs all the context it needs, attempts a fix, and raises a PR - all within minutes of the client clicking "submit."

For a small bug, that's the difference between 30 minutes of active developer time and a 2-minute PR review.

"A small bug used to mean a developer spending 30 minutes just getting to the point of writing a fix. Now it's a two-minute PR review. The work still gets done - it just happens automatically." - Jamie Curnow

The flow hasn't hit a live client project just yet - nothing's at QA stage right now - but it's been validated end-to-end in a real test environment. Real Marker project. Real bug. Real code out the other end. When the next project reaches QA, it's ready.

The team are also eyeing up the Hiyield website as the next place to run it. A backlog of smaller fixes has been quietly accumulating for months - not because they're hard, but because pulling a developer off client work for a minor tweak is hard to justify. This changes that maths completely.

"We've got a backlog of smaller fixes on our own site that have been waiting months because they're never quite the priority. This will really speed things up," - Lyssa-Fêe Crump, Head of Marketing

That's what this whole thing points at, really. A QA process where the bottleneck isn't developer availability - it's developer sign-off. The fixing happens. The human just checks the work.

They’re just getting started.