I’m a developer who spent 3 months embedded across multiple enterprise project deliveries. Here’s what I noticed.
The Principal-Agent Problem and Information Asymmetry
When the person managing a vendor can’t evaluate what the vendor actually produces, the vendor holds all the information power. That’s the principal-agent problem — and it’s quietly expensive.
Picture an IT manager who can’t read a codebase reviewing a vendor’s delivery. All he can do is click through the UI, test a few functions, and see if things appear to work. He signs off, hands it to the end users, and moves on.
Two weeks later — server down. Something crashes. Users escalate to the IT manager. The IT manager turns to the vendor. The vendor says it’s fixed. The IT manager relays that upstream.
Sound familiar? This cycle plays out constantly in enterprise environments. And here’s the uncomfortable truth: it didn’t happen by accident.
Why Companies Do This Intentionally
Hiring non-technical managers to oversee vendors isn’t stupid. It’s a deliberate tradeoff.
Non-technical managers are cheaper to hire, easier to replace, and often genuinely excellent at stakeholder communication. They smooth relationships, manage expectations, and keep projects politically on track. Under normal conditions, with stable budgets and reasonable vendor quality, this model works well enough.
The problem isn’t the model itself. The problem is what happens when conditions change.
When Budget Constraints Hit
Economic downturn. Layoffs. Budget cuts. Meanwhile, users demand more projects because their own workloads increased and they need tools to keep up.
The IT manager is now two to three times busier — not building anything, just coordinating. More vendors. More communication. More handoffs.
And vendors, sensing the pressure, don’t get cheaper in any meaningful way. Discounts come with quality reductions. Inflexibility increases. The vendor knows you need them, and they know you can’t fully evaluate what they deliver.
This is where the bottleneck becomes visible — but by then it’s already expensive.
The "Number" That Nobody Questions
A simple enterprise form submission app. Static frontend, a serverless function, hostable on an S3 bucket for near zero ongoing cost. Straightforward for any competent developer to build in days.
Six figure budget. One month timeline. Approved.
Why? Because the IT manager doesn’t know what it should cost. The end user doesn’t know.
Only the vendor knows — and the vendor has every incentive to keep it that way.
This isn’t a vendor problem. It’s an information asymmetry problem. And it compounds quietly until a budget crisis makes it impossible to ignore.
The Structural Issue
Most enterprises separate technical execution from technical oversight entirely. Under normal budgets, this is manageable. Under constraints, it becomes the most expensive decision you never noticed you made.
CEOs tend to underestimate in-house builders and overestimate vendor output. When both are happening simultaneously during a budget crunch, bad outcomes don’t just add — they multiply.
The No-Code Trap
Budget is tighter now. Outsourcing everything to vendors isn’t sustainable. So the IT manager thinks creatively — and lands on what sounds like a brilliant middle ground.
No-code. Low-code. Power Automate. Power Pages. Let the platform do the heavy lifting.
On paper, this makes sense. Microsoft manages the infrastructure. Licensing is predictable. Non-technical staff can theoretically build and maintain workflows without developer involvement. The IT manager can stay in control without needing to understand what’s happening under the hood.
It works. Until it doesn’t.
The Walls Users Hit
The first wall is customization. Users start with simple requirements, get comfortable, and then inevitably ask for more.
- Can it do this?
- Can we add that condition?
- What if the input looks like this instead?
No-code platforms are excellent within their boundaries. The boundaries just aren’t visible until you’re already against them.
The second wall is performance.
A Power Automate flow with enough conditions and connectors can take three hours to process something a simple script handles in seconds.
Nobody told the users that when they started building.
By the time they notice, hundreds of records are already running through a pipeline nobody wants to touch.
The third wall is auditability.
When security or compliance teams ask how data is being handled, who has access, where credentials are stored — the answer gets uncomfortable fast. Low-code platforms abstract away exactly the things auditors want to see. Source code is hard to produce. Logic is buried in visual flow diagrams. The IT manager can’t answer the question, and neither can the platform documentation.
The fourth wall is the one future developers hit.
A new developer joins, opens the workflow tool, and stares at a canvas with a thousand connected actions, nested conditions, and branching trees built by five different people over eighteen months with no documentation and no naming conventions. Developer call this "Spaghetti".
There is no architecture. There are no layers. There is just accumulated decisions, each one reasonable at the time, collectively forming something nobody fully understands anymore.
This is technical debt — just dressed up in a drag-and-drop interface.
The Misunderstood Promise of Low-Code
Low-code platforms are genuinely excellent at one thing: integrating with existing ecosystems. Power Automate connecting Microsoft products together is a legitimate use case. It saves time, reduces friction, and doesn’t require custom development for straightforward workflows.
But that’s not how it gets used under budget pressure. Under budget pressure, it becomes a construction tool for complex business logic, a replacement for proper application development, a way to avoid hiring developers. And that’s where the promise breaks down.
Because low-code doesn’t mean no skill required. It means the skill required is less visible — until the system breaks, scales, or needs to change. A competent developer, especially today with AI dramatically amplifying individual output, can build what these platforms produce with more flexibility, better performance, full auditability, and architecture that a future developer can actually reason about.
The platform abstraction isn’t free. You pay for it in constraints you don’t see coming.
Back to the IT Manager
So the vendor route got expensive. The no-code route hit its ceiling. What’s left?
The IT manager calls a meeting with the users.
“You know, some of this you could probably just… do manually, right?”
The room goes quiet.
Everyone smiles politely. Nobody says what they’re thinking.
And the backlog keeps growing.
Top comments (0)