The Three-Vendor Problem

Most organisations solving for a fragmented vendor stack do one of two things: (1) consolidate to a single vendor who owns everything, or (2) add more governance to coordinate the existing vendors.

Both approaches miss the structural cause. The problem isn't the number of vendors. It's that accountability for outcomes sits nowhere. Each vendor is accountable for their deliverables. Nobody is accountable for the site converting.

We inserted accountability for outcomes into the system without displacing any of the existing vendors. Halcrow still owns application engineering. ITMD still owns infrastructure. Halcrow owns the outcome — the conversion rate, the uptime, the velocity of iteration.

Law 2: Consultants sell deliverables. The outcome is someone else's problem. We structured this engagement the opposite way.

The Compound Effect of Proximity

Five years of embedded proximity produces something that a project-based engagement never can: compound learning about a specific business. We know that Bow Wow Meow's customers are often first-time pet owners who don't fully understand how insurance works. We know the breed selector is a genuine differentiator but isn't prominent enough in the acquisition funnel. We know that the quote form converts better when claims transparency is shown earlier. We know which plugins are high-risk and which are stable.

That knowledge didn't come from a discovery phase. It came from five years of operating inside the system and watching what happens.

Law 6: You can't document your way to the right outcome. No amount of handover documentation would transfer this — it lives in the ongoing relationship.

The Laws in Practice

Law 1 (Distance is the enemy of speed): Three-vendor distance collapsed through embedded coordination, not vendor consolidation.

Law 3 (Speed dies in approval): Pre-agreed authority for testing decisions eliminated approval loops for individual experiments.

Law 5 (Earlier beats perfect): Small tests deployed fast, learnings applied immediately, rather than large changes deployed after months of planning.

Law 8 (Activity is not progress): Annual roadmap planning replaced by continuous experimentation. DORA metrics measure what moves, not what gets done.

Law 9 (The constraint is usually organisational, not technical): The website was technically capable of A/B testing from day one. The constraint was the coordination overhead required to run a test across three vendors. We fixed the coordination, not the technology.

The Pattern This Reveals

High-traffic acquisition sites don't fail from bad technology. They fail from slow learning.

Bow Wow Meow had 10,000’s monthly visitors and didn't know whether a page change would help or hurt conversion — not because they lacked analytics, but because the cost of running a test was too high to run tests regularly.

Any business with a website that converts visitors into customers faces this problem. The gap between "we should test this" and "we tested this and learned from it" is almost never a technology gap. It's a structural gap: who owns the outcome, who can make decisions without approval, who is accountable when the test doesn't ship.

The embedded proximity model solves for this directly. When your technology partner is accountable for your conversion rate, not for their deliverables, the incentive is to run more tests faster — not to deliver more features on a longer timeline.