When the Big Vendor Builds Your PoC, You Inherit Their Problems

A global pharma company needed to migrate a clinical platform to Azure. Important system, complex domain, real regulatory constraints. The kind of thing you want to get right. So they did what big enterprises do: they brought in one of the big cloud vendors’ consulting arms to build a proof of concept.

Reasonable decision, on paper. Who better to show you how to use a platform than the people who built it? They know every service, every integration pattern, every best practice. They’ve done this a hundred times. They’ll get you up and running quickly, prove the art of the possible, and hand over a working prototype that your team can take forward.

That’s the pitch. Here’s what actually happened.

The PoC that impressed everyone and helped nobody

The vendor consultants arrived, did their discovery, and built a proof of concept over a few months. And it was impressive — in a demo. They used every shiny service in the platform’s catalogue. The architecture diagram looked like a transit map. ARM templates defined infrastructure that used services I’d bet half the in-house team had never heard of. Kubernetes was in there, configured in a way that was technically correct and operationally impenetrable.

The demo went well. Stakeholders were impressed. Boxes were ticked. The consultants produced a handover document, shook hands, and left.

Then the in-house team tried to take it forward.

They couldn’t. Not because they were bad engineers — they were perfectly competent. But the thing they’d inherited was built by people who understood the platform at an expert level and had no constraints on complexity. Every service was configured to showcase what the platform could do, not what the team needed it to do.

The ARM templates were dense, brittle, and nearly impossible to modify without breaking something. The Kubernetes configuration was over-engineered for the actual workload. Monitoring was set up using a combination of services that created a dependency graph nobody could follow. The whole thing worked — in the sense that it ran — but nobody could confidently change it, extend it, or debug it when something went wrong.

They were stuck. They had a proof of concept that proved the concept but couldn’t become a product. That’s when I got the call.

What I actually found

When I got in and started pulling things apart, the pattern was clear. This wasn’t malice. It wasn’t even incompetence. It was incentive alignment.

ARM templates everywhere. The infrastructure was defined entirely in Azure Resource Manager templates — Microsoft’s native infrastructure-as-code format. ARM templates are JSON. Extremely verbose JSON. They’re powerful, they’re first-party, and they’re what Microsoft’s own consultants reach for because it’s their tool. But they’re also an absolute nightmare to maintain at scale. No loops. No real abstraction. Hundreds of lines to define what Terraform does in twenty. The in-house team had some Terraform experience. They had zero ARM template experience. Nobody asked.

Over-engineered Kubernetes. The AKS cluster was configured with multiple node pools, custom autoscaling policies, pod disruption budgets, network policies, and a service mesh. For a proof of concept. For a workload that, at the PoC stage, had about four services and negligible traffic. It was production-grade configuration for a prototype — which sounds responsible until you realise that nobody on the in-house team knew how to operate any of it.

Too many services. The architecture used Azure Front Door, Azure API Management, Azure Key Vault, Azure Monitor, Azure Log Analytics, Azure Container Registry, Azure Service Bus, and a few others I’ve probably blocked out. Each one individually justifiable. In aggregate, a sprawling dependency graph that required expertise across a dozen Azure services to understand, let alone troubleshoot.

No consideration for the team. This is the fundamental problem. The consultants designed for the platform. They didn’t design for the people who’d maintain it. At no point did anyone ask: “Can the team that’s going to own this actually operate it? Do they have the skills? Is this the simplest architecture that meets the requirements, or is it the most comprehensive one?”

What I did about it

The fix wasn’t dramatic. It was mostly subtraction.

ARM to Terraform. I migrated the infrastructure definitions from ARM templates to Terraform. The in-house team already had Terraform experience. The modules became readable. Changes became predictable. The team could actually modify infrastructure without fear. This wasn’t a technical upgrade — Terraform and ARM can define the same resources. It was a team upgrade. The infrastructure was now expressed in a language the people responsible for it could speak.

Simplified Kubernetes. I stripped back the AKS configuration to what the workload actually needed at that stage. Single node pool. Standard autoscaling. No service mesh. Pod disruption budgets and network policies could come later, when the system was in production and the team understood why they needed them. You don’t put training wheels on a bike and then bolt on a racing gearbox. You match the configuration to the team’s maturity and the system’s actual requirements.

Reduced the service count. Some of those Azure services were genuinely needed. Some were there because the consultants defaulted to the Microsoft-recommended architecture for a much larger system. I consolidated where possible, removed what wasn’t needed yet, and documented clear criteria for when to add complexity back. Simplicity isn’t the absence of capability — it’s the discipline to add capability when you need it, not before.

The result wasn’t as impressive in a demo. It was vastly more useful in practice. The team could understand it, change it, debug it, and — critically — ship it to production.

The pattern

This wasn’t a one-off. I’ve seen this pattern repeatedly across my career, in different organisations, with different vendor consulting arms. The specific technologies change. The dynamic doesn’t.

Vendor consultants optimise for their platform, not your team. Their incentive is to show you what the platform can do. The more services they use, the more value they demonstrate, the more compelling the case for the platform. They’re not trying to make your life difficult — they’re trying to make their platform look good. Those are different goals, and the gap between them is where the problems live.

Reference architectures are not products. Microsoft publishes Azure Architecture Center reference architectures. AWS has Well-Architected. Google has their Cloud Architecture Framework. These are useful as starting points and reference material. They’re terrible as blueprints to implement wholesale. They’re designed to be comprehensive, not appropriate. They cover every scenario because they don’t know your scenario. When a vendor consultant builds your PoC, they tend to implement the reference architecture rather than the subset of it that fits your situation.

The demo is not the product. A PoC that works in a demo environment, with demo data, under demo conditions, operated by the people who built it, proves almost nothing about whether it’ll work in production, with real data, under real conditions, operated by people who didn’t build it. The gap between “it works when I show it to you” and “it works when you run it at 3am” is enormous. That gap is where most PoCs go to die.

Nobody asks “who maintains this after you leave?” This is the question that should be asked in the first meeting and repeated in every meeting after that. The vendor consultants are temporary. The system is permanent. If the people who’ll own the system long-term aren’t involved in building it, can’t understand how it works, and aren’t gaining skills as the PoC progresses, then the PoC isn’t building towards production — it’s building towards a handover nobody can receive.

How to not get burned

I’m not saying never use vendor consultants. They have genuine expertise. They can accelerate your understanding of a platform. They can help you avoid pitfalls that they’ve seen a hundred times. But you need to manage the engagement differently than most organisations do.

Insist on your tools, not theirs. If your team uses Terraform, the consultants should use Terraform. If your team uses GitHub Actions, the consultants should use GitHub Actions. The PoC should be built with the tools your team will maintain it with. If the consultants can’t or won’t work with your toolchain, that tells you something important about how much they care about your long-term success versus their short-term deliverable.

Embed your engineers. Don’t let the vendor consultants go off and build something in isolation. Your engineers should be pairing with them, reviewing every pull request, asking questions, and building their own understanding as the PoC develops. If the PoC is a black box that gets handed over at the end, it’s worthless. The knowledge transfer should happen during the build, not after it.

Constrain the architecture. Before the consultants write a line of code, agree on the services they can use and the complexity budget they have. Make it explicit: “We want the simplest architecture that proves this concept, using no more than N services, with the assumption that a team of five mid-level engineers will operate it.” If the consultants push back on simplicity constraints, they’re optimising for their demo, not your outcome.

Define “done” as “your team can ship it.” The PoC isn’t done when it works. It’s done when your team — without the consultants in the room — can deploy it, modify it, debug it, and explain how it works. If your team can’t do that, the PoC has failed, regardless of how well the demo went.

Budget for the rationalisation. Assume that whatever the vendor consultants build will need simplification before it goes to production. Budget time and money for that work. It’s not waste — it’s the translation step between “what the platform can do” and “what your team should do.” Skipping this step is how you end up with an unmaintainable system that slowly becomes everyone’s least favourite problem.

The deeper issue

This isn’t really about vendor consultants. It’s about a fundamental misunderstanding of what makes software successful in production.

The best architecture for a system is not the most technically sophisticated one. It’s not the one that uses the most services, or the one that scores highest on some maturity model, or the one that looks most impressive in a diagram.

The best architecture is the one that your team can build, operate, debug, and evolve. Full stop.

That calculation depends on your team’s skills, your organisation’s operational maturity, your actual requirements (not the requirements you might have in two years), and your tolerance for complexity. It’s a deeply contextual judgement. It can’t be made by someone who doesn’t know your team, won’t be around for production, and has an incentive to showcase their platform.

I’ve been contracting for over 25 years. The most impactful work I’ve done has almost never been adding complexity. It’s been removing it. Taking a system that was over-engineered by well-meaning, highly skilled people and making it simple enough for the team that actually owns it to operate with confidence.

That’s not glamorous work. It doesn’t demo well. Nobody writes a case study about it. But it’s the difference between a PoC that becomes a product and a PoC that becomes a cautionary tale.

If a vendor is building your proof of concept right now, ask yourself: when they leave, can your team ship this? If the answer isn’t a confident yes, you don’t have a proof of concept. You have a proof of their concept. And that’s not the same thing at all.