The engineer in the room

There is a particular kind of marketing proposal that reads beautifully and cannot be built. Unified customer profiles across four systems that share no key. Real-time personalisation on a site with a twelve-second cold start. Server-side tracking on a platform the client's developers are not allowed to deploy to. Each of these has been promised to someone in the last year, by somebody, in a deck.

The failure is rarely dishonesty. It is that the person writing the strategy and the person who would have to implement it never spoke before the signature.

Why marketing work keeps becoming engineering work

A decade ago the boundary was clean. Marketing owned the message and the media; engineering owned the product. That boundary has quietly dissolved. Consent management is a legal and architectural problem. Attribution is a data-modelling problem. Marketing automation is a systems-integration problem wearing a friendly interface. Anything with "AI" in the name is an infrastructure problem with a demo attached.

Which means an agency that cannot evaluate technical feasibility is guessing — and passing the risk of that guess to the client.

Our answer: an engineer reviews the plan

We work with Badih Aldroubi as a technical advisor. Proposals with a significant engineering surface — data integrations, tracking architecture, platform selection, anything touching AI systems — get reviewed before they reach a client, not after.

The value is not that a reviewer adds sophistication. Usually it is the opposite: the review removes things. A recommendation survives it only if someone who would have to build it agrees it can be built, by this client, with the people and systems they actually have.

The point of the review is not to make the plan cleverer. It is to make sure the plan is one somebody can actually ship.

The questions that tend to change the plan

• Who maintains this in six months? An integration that requires its author to keep working here is not a deliverable, it is a liability with a nice dashboard.
• What happens when it fails? Every pipeline fails eventually. The design question is whether it fails loudly or quietly — quiet failures are the expensive ones, because they are discovered in a quarterly review.
• What does this do to page performance? Tags, pixels and personalisation scripts all have a cost, and it is paid by the same conversion rate the campaign is trying to lift.
• Is the data model actually capable of this? Most "advanced measurement" requests are blocked by a missing identifier, not a missing tool.
• What is the smallest version that proves it? Nearly every ambitious integration has a two-week version that tests the assumption before anyone commits to the six-month one.

Where it matters most right now

AI has widened the gap between what is demonstrable and what is deployable. A model that produces a convincing result in a notebook is a long way from a system that runs reliably against live customer data, handles the cases nobody scripted, and can be explained to a regulator or a finance director.

We build AI into client work — predictive models, automation, applied tooling — and the technical review is precisely what keeps that responsible. The interesting question about an AI feature is almost never whether the model works. It is what happens on the day it is confidently wrong, and whether anyone will notice.

If you have had a strategy delivered that your engineering team then quietly declined to build, the problem was upstream of your engineers. It is worth fixing before the next agency cycle.