Building Platforms For Vendor-Led Enterprises

A lot of my customers don't build their own integrations. They hire someone who does, for the length of a project, and then that someone leaves.

I keep running into the same customer shape. A business team with no technical know-how of its own, running a project on a vendor's time and a vendor's keyboard. The vendor ships the integration, invoices the last milestone, and moves on to their next engagement. What they leave behind becomes the customer's problem the moment something breaks.

In this article I want to unpack why that model quietly erodes integration quality, what I believe a platform aimed at this specific situation needs to assume about its users, and which capabilities actually move the needle rather than just adding another policy document nobody reads.

The Vendor Leaves, The Business Team Stays

This is the part that's easy to miss if you've never sat inside one of these organisations. The people making the decision to integrate a new system are, quite reasonably, not the people who know how to integrate a new system. So they fly in the expertise: a systems integrator, a boutique vendor, a freelance specialist, whoever is "behind the keyboard" for the duration of the project.

That's not a bad model on its own. Specialisation exists for a reason.

Though the trouble starts the moment the project ends and the vendor's access is revoked. The customer's own integration team — the people who actually have to run this thing in production — gets pulled in two directions at once. During the project, they're fielding ad-hoc requests from a vendor who needs an endpoint, a credential or a decision made by end of day. After the project, they inherit whatever was built, with whatever documentation the vendor felt like leaving behind.

For better or worse.

I've seen "for better" plenty of times. I've also seen a canonical model quietly bypassed because nobody on the vendor side knew it existed, an API shipped without a single validation rule because nobody enforced one, and a support inbox that fills up six months after go-live because the person who understood the integration is now working for a different customer entirely.

Governance Belongs In Tooling, Not In A Slide Deck

The reflex response to this is more governance. Write the principles down, hold a review board, make vendors sign off on an architecture document before they start. I understand the instinct — it's the same instinct I described when writing about API governance execution more broadly. But a PowerPoint has no opinion about the API description a vendor actually ships. It can't fail a build. It can't reject a pull request.

Enterprise architecture that lives exclusively in slides is enterprise architecture that vendors will never open. They have their own deadline, their own tooling, and precisely zero incentive to read your governance document before they start writing code.

What I believe instead is that the principles and patterns you want enforced need to be executable, and that expertise needs to sit at the edge of the estate rather than centralised in a review committee three approval steps away. A federated operating model — where the platform itself carries the know-how instead of a person who has to be pinged for it — is what makes this workable at the pace vendors actually operate on.

This is the difference between a rule that says "APIs must follow our naming conventions" and a rule that fails the pipeline when they don't. One is a hope. The other is enforcement that happens whether or not anyone remembers to check.

Zero-Ticket Integration Is The Actual Goal

Here's where I think most governance efforts stop too early. Enforcement alone gets you compliance, and compliance alone doesn't get vendors to like your platform — it gets them to route around it.

The platform has to be worth using on its own merits, not just on pain of rejection. If the fastest way for a vendor to integrate with your estate is also the way that keeps your architecture principles intact, you've won without a single review meeting. If the fastest way is to skip your platform and ask a human for a shortcut, you've lost regardless of what the governance document says.

That's what I mean by zero-ticket development. A vendor should never need to open a support ticket to understand what's available, how to consume it, or how their data maps onto your canonical model. The moment they do, you've reintroduced the ad-hoc overload this whole thing was supposed to prevent.

So the angle can't only be policy enforcement. It has to be facilitation and speed, delivered well enough that vendors don't want anything else.

What The Capabilities Actually Need To Do

I keep coming back to three things a platform like this needs to nail, in this order.

It needs to make the customer's own business team want it. Adoption doesn't start with vendors — it starts with the people who feel the benefit first. If a business team experiences what it's like to onboard a vendor without the usual chaos, they'll insist on the platform the next time a new vendor walks in. That's a stronger enforcement mechanism than any mandate from architecture.

It needs to do the heavy lifting for the vendor, not just watch them. SDK generation from the API description. Validation of that description before a single line of integration code gets written. A unified API surface so a vendor isn't reverse-engineering which of your seventeen internal systems they're actually supposed to talk to. Data mapping onto your canonical model, so the vendor's payload becomes your shape automatically instead of by convention nobody checks.

It needs to lower the barrier to entry relentlessly. A vendor who has never seen your estate before should be able to find what's available, read documentation that actually explains it, and see a diagram that makes the topology click — fast. Every hour a vendor spends guessing is an hour your integration team spends answering questions that a platform should have already answered.

Closing Thoughts

In an environment where you own the whole stack, governance can afford to be a conversation. In a vendor-led environment, I don't think it can:

• A conversation-based approach assumes continuity — the same people, the same context, over time
• A vendor-led environment guarantees the opposite — new people, no context, every project

Though the fix isn't to fight the vendor-led model. It's to build a platform that assumes it from the start — one that enforces what matters, facilitates what's tedious, and gets out of the way for everything else.

If a vendor never wants to leave your platform for their old way of working, you've built the right thing.