DEV Community: Kingson

Patterns of Inefficiency in Enterprise and a Lean Alternatives - Part 1

Kingson — Thu, 09 Apr 2026 07:25:48 +0000

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.

Patterns of Inefficiency in Enterprise and a Lean Alternatives - Part 2

Kingson — Thu, 09 Apr 2026 07:25:27 +0000

What follows isn’t a proven framework. It hasn’t been battle tested in production. It’s a direction I’ve been thinking about — born directly from the patterns I described in Part 1. Take it as a proposal, not a prescription.

The Smallest Viable Unit

Every problem in Part 1 traces back to the same root cause:

people making decisions couldn’t evaluate what was being built.
Vendors exploited that gap.
No-code platforms obscured it. And eventually the IT manager ran out of roads.

So what’s the minimum viable team that closes that gap — without blowing the budget?

I think it’s three.

One Business Analyst
One Developer
One AI Agent

I call this "TripleOne" — the smallest unit capable of delivering real enterprise high quality in house software in a budget-constrained environment.

The Three Roles and Why Each One Matters

The Business Analyst is not just someone who talks to users. In this model, the BA is the translation layer between user chaos and developer clarity. Users don’t know what they want in technical terms — they know what problem they have. The BA’s job is to capture that, structure it into clear requirements, and protect the developer from scope creep and moving goalposts. Without this role, developers build the wrong thing precisely and efficiently. With it, every build starts with a shared understanding of what done actually looks like.

The AI Agent writes the code. This is what makes TripleOne modern and distinct from just “hire a small team.” A competent developer paired with AI can produce what used to require three to five engineers. The agent handles boilerplate, accelerates implementation, and reduces the time between requirement and working software dramatically. This isn’t hypothetical — it’s already how the best lean engineering teams operate today.

The Developer is not just a coder in this model. The developer is the technical conscience of the unit. They oversee what the agent produces, make architectural judgements, catch what AI gets wrong, and ensure the system is maintainable by the next person who touches it. This is precisely the role that was missing in Part 1 — someone who can actually evaluate output, ask hard questions of vendors, and know when a six figure estimate for an S3 hosted form app is absurd.

Together these three roles directly answer the failures from Part 1. The information asymmetry shrinks because technical oversight is built in. The vendor dependency reduces because the team can build in-house. The no-code ceiling disappears because the team writes real code with real architecture.

One Platform, Not One App

The “one app” in TripleOne is probably the most important thing to get right — and the easiest to misunderstand.

It doesn’t mean you build one thing and stop. It means you build one centralised platform that everything else grows from.

Here’s what that looks like in practice.

The platform starts with an Auth Module — a single source of truth for user identity and role based access control. Every module that gets added inherits this. Users are authorised once, centrally, with clear permission boundaries. No more separate login systems per tool, no more credential sprawl, no more security audits that produce uncomfortable silences.

The frontend is a NextJS/React application built and hosted on S3 — simple, fast, very cheap to run, and easy to extend. Built on JAMstack principles, it separates the presentation layer cleanly from the business logic. Adding a new user-facing module means adding to this application, not spinning up something new from scratch.

The backend uses serverless functions for the API layer — scalable by default, again, very cost efficient at low to medium load, and straightforward to reason about. One SQL database handles relational data. Object storage handles files and assets. Roles and responsibilities are clearly separated at every layer.

When a user requests a new application, the answer isn’t “find a vendor” or “let’s see what Power Automate can do.” The answer is: add a module. One new frontend section. One new set of backend functions. Plugged into the same auth, the same database structure, the same deployment pipeline.
The platform compounds over time. Every module added makes the next one faster to build. The architecture stays coherent because one developer is making the judgement calls throughout. The BA ensures every addition is grounded in what users actually need.

What This Solves — And What It Doesn’t

TripleOne isn’t a silver bullet. A few honest caveats before anyone tries to implement this.

It requires the right developer. Someone who can work with AI effectively, make sound architectural decisions, and resist the pressure to cut corners when timelines tighten. That person exists — but finding them matters enormously.

It requires organisational trust. The IT manager, the department head, the budget approver — someone in the chain needs to believe that one developer with AI can outperform a vendor team. That’s a cultural shift, not just a technical one. In many enterprises, it’ll be the hardest part.

And it doesn’t fix the oversight problem on its own. If the same non-technical manager is still approving scope and signing off on delivery, some of the information asymmetry remains. TripleOne works best when the developer has a direct line to stakeholders — not filtered through layers of people who can’t evaluate what they’re seeing.

Why I Think This Direction Is Worth Exploring?

Enterprise software doesn’t have to be expensive to be good. It doesn’t require six vendors, a no-code platform hitting its ceiling, and a backlog full of things users were told to do manually.

The tools exist today to build maintainable, secure, scalable applications with a team this small. AI has genuinely collapsed the minimum viable team size for software delivery. The architecture patterns are proven — startups have been building this way for years.

What’s missing in most enterprises isn’t budget. It’s the belief that a leaner path is possible.

TripleOne is my rough attempt to sketch what that path looks like. It needs refinement. It needs people smarter than me to poke holes in it. It needs someone brave enough to actually try it.

But every framework starts as someone’s half-formed idea written down.