— Contents +
9 months, 50 sites, zero developer calls
By spring–summer 2025, we had been working with a US marketing agency for about 9 months. We had shipped roughly 50 WordPress sites in that window. All local-business: dental, legal, veterinary, optometry. All built on the same templated stack: Astra Pro plus Elementor Pro, against the agency’s preset library.
In those 9 months, no developer from our side spoke directly to a developer from theirs. Everything ran through a layer of management on both ends: a Redmine ticket here, a Google Docs comment there, a row in a template tracker. Decisions arrived intact. The managers on both sides knew their job. Nothing dropped.
Except one thing. And that one thing piled up quietly.
What kept piling up
Small bugs. Individually they were nothing: a mobile spacing offset that didn’t match the next block; sometimes a CTA button that inherited the wrong preset color; on one site a section heading rendering in body typography. None was a ship-blocker. The agency caught each one in their QA pass, opened a separate ticket, we closed it in 10 minutes. The loop ran.
But the same bug kept reappearing every third or fourth site. The mobile spacing offset, recurring. A CTA button color inheriting from the wrong preset, again. The section heading in body typography, a fourth time that month. The manager handed it over as a new defect. For them it was new: new build, new ticket, new fix. The fact that we had patched the same bug three weeks earlier on a different site did not live anywhere in the ticket system.
This is the thing async carries worst. It carries the fact of a bug. The source of the bug doesn’t fit: to see it you have to be holding twenty previous builds in your head and say “hold on, that’s the fourth time. It’s wired into our base scaffold somewhere.” No manager can do that. Nobody can do that except a developer who sits in those builds every day.
The first call
It did not start as a big decision. One of our developers dropped it into chat one afternoon: “that spacing again.” Four of us sat down: 2 ours, 2 from the agency. No account managers. 40 minutes.
The agenda was one thing: walk the last 10 sites and, for every small bug that had repeated, find where it gets introduced. Not “how do we fix it on this ticket”. We knew that already. Where in the process the bug first appears, and what we’d change so it never appears on the next site, or the site after, or the site after that.
By the end of those 40 minutes we had a list of 7 sources. 6 were ours: a default Astra preset we hadn’t noticed was slightly different from the agency’s; a templated PHP partial copied from an older build, dragging an old CSS namespace; a way of setting mobile breakpoints that drifted between our setup and theirs by one breakpoint. The 7th was shared: neither side had a single description of which blocks in a typical page were mandatory and which were optional.
7 sources in 40 minutes. Before that call, we had been catching them one ticket per week, for 9 months.
What it changed
Not the build speed. Speed hadn’t really been the issue. We were shipping fast already. What changed was the count of new tickets caused by repeating bugs: it went to near-zero across the next two builds. Not because we became more careful, but because the sources had been closed. The bugs physically stopped getting produced.
A second thing changed, quieter. The partnership now had a channel for the technical “how” the management layer could not carry. We used it rarely (that was the design): maybe once every six weeks before a larger build. But it existed, and knowing it existed changed how each side entered a build before work started.
Managers carry decisions across the gap. They cannot carry the source of a repeating bug — that doesn’t fit in ticket format. Developers either agree it directly, or it compounds for months.
— Working note · 2025
What this suggests
This is not an argument against async work. We still run projects primarily through tickets and workbook threads. Async is searchable, keeps a record, scales across time zones. None of that changed, none of that should.
The argument is narrower. Async with managers in between is excellent at carrying decisions. It is poor at carrying sources of repeating bugs. Only the people sitting in the code every day see them, and they see them when they talk to each other. The management layer cannot run that conversation, because project-management vocabulary does not have words for it.
If you are a marketing agency running WordPress builds through a subcontractor entirely async, and the same minor bug has reappeared in your tracker more than twice in the past 6 months. The question is not whether the tickets are working. They probably are. The question is whether your developers have ever directly walked your subcontractor’s developers through where that bug originates — or whether you are fixing it for the 20th time and closing the ticket.
How to check this on your own
Open your tracker for the last 6 months. Group closed tickets not by site, but by bug character. If the same small bug shows up across 3 or more builds, you’ve just found a source that would otherwise have lived in your system another 9 months.
We should have set that call up sooner. We didn’t because it felt like it shouldn’t be necessary: good documentation, sound process, experienced managers should close everything. Usually they do. On repeating bugs specifically, they don’t; and nothing tells you that until the people doing the work are in the same room for 40 minutes.