Forem: Nigel Tape

AI Coding Adoption at Enterprise Scale Is Harder Than Anyone Admits

Nigel Tape — Wed, 04 Mar 2026 11:37:34 +0000

AI Coding Adoption at Enterprise Scale Is Harder Than Anyone Admits

The hype around AI coding tools usually starts with a developer typing faster. The enterprise version starts somewhere else entirely: security review, architecture review, procurement, compliance, legal, and then a long meeting where someone asks whether prompts are being logged.

Its core complaint is not that AI cannot write code. It is that downstream testing, security, rollback processes, and organisational controls become the real bottlenecks once you try to use AI seriously inside a large company.

That is the part many leaders underestimate. AI coding feels like a lightweight productivity tool when seen from an individual contributor's desk. At enterprise scale, it behaves more like an operating model change. It touches code quality, delivery stability, trust, governance, and accountability all at once. That is why so many rollouts look brilliant in a demo and clumsy in production.

AI makes the keyboard faster before it makes the organisation wiser.

What the Market Gets Right

There is real upside here, and pretending otherwise makes the argument weaker.

Stack Overflow's 2025 survey says 84% of developers are either using or planning to use AI tools in development.
51% of professional developers say they use AI tools daily.
McKinsey's 2025 State of AI says 88% of respondents report regular AI use in at least one business function.

Those numbers matter because they explain why AI coding tools are no longer a fringe experiment. The market has already voted. Developers are using them. Executives are buying them. Vendors are treating them as table stakes. The question is no longer whether AI enters the development workflow. The real question is whether enterprises can absorb it without quietly trading one bottleneck for three new ones.

Where the Story Starts to Crack

This is where things get interesting, and a little less shiny.

DORA's research found that greater AI adoption is associated with improvements in:

documentation quality (+7.5%)
code quality (+3.4%)
code review speed (+3.1%)

On paper, that sounds like a clean victory lap. But the same research also found that a 25% increase in AI adoption was associated with an estimated:

1.5% drop in delivery throughput
7.2% drop in delivery stability

That combination should make every engineering leader pause.

It suggests that AI may improve the front-end of development work while making the back-end of delivery more fragile. In plain English, teams may draft faster, explain faster, and review faster, while still shipping slower or less reliably because more generated code creates more review surface, more testing load, and more opportunities for subtle defects to slip downstream.

The demo metric is speed-to-snippet.

The enterprise metric is safe, boring, repeatable production change.

Why Enterprises Slow the Rollout

From the outside, enterprise caution looks stodgy. From the inside, it looks expensive but rational.

When a code assistant touches internal repositories, architectural patterns, secrets, or customer-adjacent workflows, the tool is no longer just "autocomplete with ambition." It becomes part of the company's risk surface. That is why adoption gets tangled in multiple review lanes at once.

Here is what typically slows a rollout:

Security asks what code, metadata, or context leaves the boundary.
Legal asks about IP, liability, indemnity, and acceptable use.
Compliance asks whether prompts, outputs, and approvals are auditable.
Architecture asks how this fits into the SDLC and where guardrails live.
Procurement asks whether the contract, support model, and pricing are fit for enterprise scale.
Engineering leadership asks the quiet killer question: "Will this actually improve delivery, or just make developers feel faster?"

None of that is fake friction. It is what happens when a company tries to introduce a tool that influences code creation without losing control of code accountability. That is the hidden tax vendors rarely headline.

The Trust Problem Is Larger Than the Adoption Story

Adoption numbers are impressive. Trust numbers are much less flattering.

Stack Overflow's 2025 survey says:

46% of developers actively distrust the accuracy of AI tools
33% trust them
Only 3.1% say they highly trust the output

That is a brutal little stat, because it means adoption is growing faster than confidence.

This matters more in enterprises than in hobby projects. In a side project, a wrong suggestion is annoying. In a regulated or revenue-critical system, a plausible but subtly flawed suggestion is a liability dressed as convenience. The more polished the output looks, the easier it becomes for teams to underestimate the cost of verifying it.

That is also why experienced developers tend to be more cautious. Not because they are anti-AI, but because they have seen enough production incidents to know that "looks fine" is one of the most dangerous phrases in software.

The Rollout Mistake Most Companies Make

Many enterprises treat AI coding adoption like a software purchase.

That is the wrong frame.

This is not just a tooling rollout. It is a workflow redesign project. McKinsey's findings support that distinction: while AI usage is widespread, only about one-third of organisations have begun scaling AI programs, and only 39% report any level of EBIT impact from AI at the enterprise level. In other words, usage is everywhere, but material organisational value is still uneven and often shallow.

The common anti-pattern looks like this:

Buy licenses quickly
Enable broad access
Publish a vague policy
Hope developer velocity magically rises
Realise three months later that review quality, testing discipline, and governance are now the real bottlenecks

That sequence almost guarantees disappointment. It optimises for tool adoption, not operational adoption.

What a Realistic Enterprise Rollout Looks Like

A sensible enterprise path looks more like this.

Start with low-risk use cases

documentation
test scaffolding
code explanation
boilerplate generation

Define usage zones

Green zone for low-risk internal utilities
Amber zone for reviewed systems
Red zone for regulated, sensitive, or high-blast-radius code paths

Keep human gates intact

mandatory code review
static analysis
dependency scanning
explicit approval for production-impacting changes

Measure outcomes that matter

review time
escaped defects
rollback rate
vulnerability rate
deployment stability
onboarding speed for new engineers

Treat policy as part of the product

what data can be used in prompts
what repositories are allowed
what must be reviewed
what must never be AI-generated without deeper controls

This is slower at the start, but it gives you a chance of achieving something better than a flashy pilot with a hidden maintenance bill.

Enterprises do not need "more AI usage."

They need cleaner rules for where AI helps, where it doesn't, and who owns the outcome.

The Real KPI Is Not Lines of Code

One reason AI coding programs get overhyped is that teams track the easiest metrics first.

Those are usually vanity metrics:

seats purchased
prompts sent
suggestions accepted
lines of code generated

Those numbers are easy to gather and almost useless on their own.

The more meaningful metrics are harder, but they tell the truth:

Did review time fall without defect escape rising?
Did documentation stay fresher?
Did production stability improve or worsen?
Did junior developers ramp faster?
Did senior engineers spend less time on boilerplate and more on architecture?
Did release confidence improve?

If AI can raise local code-related metrics while reducing throughput and stability, then a mature enterprise program has to measure both the speed gains and the downstream drag. Otherwise, you are reading only the first half of the X-ray.

My Forecast for the Next 12 to 24 Months

This part is inference, but it is grounded in the adoption and trust signals we already have.

I do not think enterprises will slow AI coding adoption. I think they will narrow it, formalise it, and become much more selective about where it is allowed. That is the likeliest path implied by widespread adoption, weak trust, and uneven enterprise value.

Here is what I expect:

AI coding will become default for draft work, especially documentation, refactoring suggestions, tests, and internal utilities.
High-risk production paths will stay heavily gated, with stricter review and tighter usage policies.
Tool sprawl will shrink, as enterprises consolidate onto fewer approved vendors with better governance and clearer contracts.
Verification will become the real bottleneck, not generation. The winning teams will be the ones that improve review, testing, and policy enforcement.
ROI pressure will intensify, because widespread usage without measurable delivery gains will not survive budget scrutiny forever.

In short, the market is unlikely to move toward "AI writes everything." It is more likely to move toward "AI drafts a lot, humans remain accountable, and governance gets sharper."

Final Thought

AI coding adoption at enterprise scale is hard because the real project is not installing a tool. It is redesigning trust, review, ownership, and delivery discipline around a new source of code generation. That's where platforms like Retool, ToolJet, Appian, etc. shine.

Engineers who lack sufficient context in the enterprise space may assume that vibe-coding tools can compete with these platforms. However, enterprise software is not simply about generating code more quickly. It must also support scale, sensitive data handling, access controls, approval workflows, audit trails, and long-term maintainability.

That is where low-code enterprise builders will continue to have an edge. They provide the guardrails, governance, operational structure, and much more that raw AI code generation alone does not.

The friction is not a sign that enterprises are backward. It is a sign that enterprise software has consequences. And in that world, a fast suggestion is only useful if it can survive the slow, unglamorous machinery of production reality.

Enterprise App Builders That Are Actually Enterprise-Ready (Top 5)

Nigel Tape — Wed, 18 Feb 2026 11:35:14 +0000

Lately, the pitch has shifted from low-code to “no-code to done” with a garnish of generative AI. Type a prompt, get an app, ship it before your tea cools. Tools like Lovable and Vibe make it look effortless.

But enterprise cares about what happens after you ship.

Who has access. Where the data lives. Whether you can audit changes. Whether you can keep regulated data inside your network. Whether your app survives real load and real humans clicking real buttons at the same time.

So this is not a list of “best app builders.” It is a list of app builders that can survive compliance, identity, governance, and the security reviews.

What “Enterprise-Ready” Really Means in Practice

If a platform can’t do these consistently, it is not enterprise-ready. It is “a cool demo that will be fun for three months and then a problem forever.”

Security posture you can evidence (SOC 2 Type II, ISO 27001 alignment/certification, pen-test reports, incident response).
Identity + access control that plays nicely with corporate reality (SAML/OIDC SSO, RBAC, SCIM/LDAP, least privilege).
Auditability (who did what, when, from where, and what changed).
Deployment flexibility (self-hosted, private cloud, air-gapped/offline options when needed).
Governance and SDLC fit (environments, approvals, versioning, rollback, predictable releases).

The Evidence Pack To Ask For (And Why Procurement Asks For It)

Check for these upfront:

SOC 2 Type II report (or a bridge letter if you are in between periods).
ISO 27001 certificate (or proof of ISMS alignment, depending on vendor posture).
Pen test summary (and how quickly high severity findings get resolved).
Data flow and shared responsibility model (especially if you are self-hosting).
Audit logging details (fields captured, retention, export/streaming options).
If healthcare data is involved: how they support HIPAA-aligned deployments, and what is required on your side (access controls, logging, encryption, policies, and any contractual requirements like a BAA depending on who is handling PHI).

That is the difference between “looks powerful” and “actually works”.

Here are five tools that won’t crumble the moment a large organisation shows up with compliance, scale, and opinions.

Important: This list is in no chronological order. The numbering is just for readability.

1) Appian

If your enterprise world is heavy on regulated workflows, approvals, and “the process is the product,” Appian tends to feel very at home. It is built for environments where governance is not optional.

Enterprise proof points

Appian maintains compliance with SOC 2 Type II, ISO 27001, and HIPAA, and notes FedRAMP for GovCloud environments.
Appian also announced its Government Cloud achieved FedRAMP High and IL5 (strong signal for sensitive public sector workloads).

Where Appian shines

Case management, process automation, and systems where “auditability plus governance” is the core requirement, not an afterthought.

2) Mendix (Siemens)

Mendix is the classic enterprise low-code workhorse. It shows up when organisations want governed development across multiple teams without turning every department into its own software company.

Enterprise proof points

Mendix has implemented an ISMS according to ISO/IEC 27001:2022.
Mendix holds SOC 2 Type II (and SOC 1 Type II) assurance reports.
Mendix has published adoption stats: 4,000+ organisations in 46 countries, 300,000+ developers, and 950,000+ applications created.

Where Mendix shines

Portfolio modernisation, multi-team development with governance, and enterprises that want a mature SDLC story without sacrificing speed.

3) ToolJet

ToolJet is the rare internal-tools builder that stays approachable for business users, but doesn’t fall apart the moment you need real logic, governance, or controlled deployments.

Enterprise proof points

ToolJet states it undergoes SOC 2 Type II audits and follows ISO 27001 standards for information security management.
ToolJet supports both JavaScript and Python code (server-side execution), so teams can add secure code when workflows get complex.
ToolJet provides audit logs capturing user actions with full context.
ToolJet supports HIPAA alignment in self-hosted deployment.
Teams at Orange, Swisscom, and Emeritus rely on ToolJet to build and run internal tools.

Where ToolJet shines

Enterprise internal apps where you want fast delivery, business-friendly building blocks, and the option to use advanced AI development, while still meeting all enterprise governance expectations. ToolJet is also suitable for very complex use-cases where the apps go beyond the boundaries of regular enterprise needs.

4) Retool

Along with ToolJet, Retool is frequently the “default” internal tools platform in engineering-led organisations, and it has matured significantly on the enterprise side. It is fast, but it is also built to pass the grown-up checks.

Enterprise proof points

Retool’s audit logs include user info, time, and can include details like queries, parameters, and user IP address.
Retool supports self-hosting (Enterprise plan), including deployment on your own infrastructure.
Retool states 10,000+ customers, both on its site and in its blog posts.

Where Retool shines

High-velocity internal apps that integrate many data sources, where you still need governance, logs, and predictable operations.

5) OutSystems

OutSystems is the heavyweight option that usually appears when an organisation wants enterprise-grade low-code across web and mobile, with mature governance expectations.

Enterprise proof points

OutSystems’ evaluation guide states its security coverage includes certifications/standards like SOC 2 Type II, ISO 27001, and HIPAA, among others.
OutSystems can be installed in a third-party private cloud or in an organisation’s own data centre for on-premises setups.
OutSystems publishes an explicit OutSystems 11 to ODC conversion guide, which is good transparency, but it also means migrations can become a real programme item for long-lived portfolios.
OutSystems itself publishes material on vendor lock-in risks and mitigation strategies, which is useful, and also a reminder to design deliberately (systems of record, loose coupling) if long-term flexibility matters.

Where OutSystems shines

Large enterprise programmes, multi-app delivery, and environments where you want predictability across SDLC and governance.

A Quick “Choose Based On Your Reality” Guide

If you want a practical way to decide without reading 40 pages of vendor PDFs:

You are process-heavy and regulated, and your app is basically a workflow engine: Appian.
You are modernising a large portfolio and need governance across many teams: Mendix or OutSystems.
You are building internal tools at scale and you care deeply about deployment control (self-hosted, air-gapped) plus auditability: ToolJet.
You want speed for internal tools, plus a reliable audit and self-hosting story: Retool.

Where “Pure AI App Builders” Still Struggle In Enterprise

AI can generate code. Sometimes it can generate an entire app. That part is real.

The enterprise problem is everything around the code:

Identity and least privilege, implemented correctly.
Audit logs that are forensically useful.
Repeatable environments, change control, and rollback.
Evidence packs for compliance and security reviews.

Until AI-native builders like Lovable, Vibe, etc. ship a first-class “proof bundle” (controls, reports, logs, governance) that stands up to procurement, most regulated teams will use them as accelerators for prototypes, then land production apps on platforms that are already fluent in enterprise constraints.

Final Takeaway

The winning strategy is boring and effective. It is also the only one that survives contact with procurement.

Start by picking platforms that can prove security controls and governance, not just promise them in a sales deck. You want evidence: certifications, documented controls, audit trails, clear deployment models, and an answer to “who can access what” that doesn’t involve three Slack threads and a prayer.

Then use AI the right way. AI is great at compressing the early stages: scaffolding, generating UI drafts, writing query logic, speeding up repetitive wiring. But in enterprise, AI should be the turbo button, not the steering wheel. The steering wheel is still identity, permissions, environments, change control, and operational ownership.

Finally, treat deployment and auditability like actual product requirements, because that’s what they become the moment your app touches real data.

Speed vs Control: The Structural Conflict Inside Enterprise Application Development

Nigel Tape — Wed, 04 Feb 2026 05:30:26 +0000

Enterprise application development is not blocked by code. It’s blocked by physics.

One side of the org is optimising for time-to-value.
The other side is optimising for blast radius.

Speed teams want fewer gates. Control teams want fewer surprises. Both are rational. Both are usually under-resourced. That’s the whole conflict.

The good organisations do not “pick a side”. They change the shape of the battlefield so speed and control stop colliding head-on.

Below are the patterns that show up again and again in large, high-scale organizations.

Pattern 1: Move Control From People Into Systems

The first mature move is simple: stop enforcing controls through meetings.

When approvals become the main control mechanism, you get:

inconsistent enforcement
bottlenecks that grow with headcount
governance that arrives late and angry
teams that route around the process

Big orgs shift control into tooling because tooling scales linearly, while committees scale like a traffic jam.

This is the practical difference between:

permissioning (human gatekeeping)
policy (automated, repeatable, visible)

Example: Netflix

Netflix is often described as fast, but the more interesting trait is systematic. Controls exist, but they are implemented as:

automated deployment workflows
mandatory observability expectations
fast rollback culture
explicit ownership per service

Net outcome: control is present, but it is not an obstacle course. It is infrastructure.

Steal this: If a control cannot be automated, treat it as a temporary workaround, not a permanent solution.

Pattern 2: Standardise the Substrate, Not the Product Teams

Enterprises that try to standardise every product team's workflow lose both speed and control.

The scalable compromise is:

keep teams autonomous at the app layer
standardise the shared substrate underneath

This means standardising:

identity and access
secrets management
logging and audit trails
deployment pipelines
baseline network rules
incident workflows

Example: Amazon

Amazon's structure makes one thing obvious: decentralisation is not a vibe, it is an engineering commitment. It only works when the platform layer is strong enough to stop entropy.

This is how autonomy survives scale:

teams can build what they want
as long as they build on top of shared foundations

Steal this: Build golden paths where the safe thing is also the easiest thing.

Pattern 3: Treat Production Readiness as a Product Requirement

In many enterprises, reliability is a separate department. That is a design flaw.

The better model is to treat operational readiness as part of the definition of done:

monitoring is not optional
runbooks exist before incidents
rollback paths are designed upfront
error budgets are real, not poetic

Example: Google (SRE Model)

The SRE framing that lands well in enterprise settings is not be reliable.

It is define reliability as a measurable budget.

If you cannot measure acceptable failure, you cannot govern it. You just argue about it.

Steal this: Make reliability measurable per service and enforce it through delivery rules, not after-the-fact policing.

Pattern 4: Governance Shifts Left, but Not as Paperwork

"Shift-left" usually gets mis-implemented as do the same approvals earlier.

The real shift-left is:

get governance input during design
implement compliance as configuration
generate evidence continuously

This turns compliance into:

constraints engineers can work with
not surprise rejections at the end

Example: ING

In regulated environments, the winning move is embedding risk and compliance earlier so delivery teams do not discover constraints at the finish line.

Steal this: If security only shows up at release time, you do not have security. You have calendar-based panic.

Pattern 5: Decentralisation Without Coordination Creates Tool Sprawl

Teams will always pick local maxima:

the library they know
the dashboard tool they like
the quickest workaround
the integration they can ship today

At small scale, this is fine. At enterprise scale, it becomes expensive because:

audit evidence becomes fragmented
incident response becomes inconsistent
onboarding becomes slow
cost control becomes guesswork

Example: Spotify

Spotify popularised a model that many enterprises copied without the invisible parts: alignment mechanisms, platform investment, and explicit ownership.

The common failure mode is lots of squads but no shared paved roads.

Steal this: Allow choice, but bound it. Give teams a curated menu, not infinite freedom.

Pattern 6: Identity Becomes the Control Plane

In modern enterprise apps, the real perimeter is not the network. It is identity.

Strong enterprise teams centralise:

authentication
authorisation
role mapping
audit trails of data access
least privilege enforcement

Because when identity is weak, every other control becomes fragile.

This is also the easiest way to reduce long-term risk without slowing delivery.

Steal this: Treat IAM and RBAC as product infrastructure, not a security ticket queue.

Pattern 7: Observability Is Governance

Audit trails are not just for regulators. They are how control teams sleep at night and how speed teams debug reality.

High-performing orgs treat observability as a first-class governance asset:

who accessed what data
what changed in prod
what was deployed, by whom, when
what failed, why, and how it was mitigated

This is where speed and control finally share the same tools.

Steal this: If you cannot observe it, you cannot govern it. You can only restrict it.

Pattern 8: Platforms Create "Safe Speed"

The long-term solution to speed vs control is platform engineering, whether you call it that or not.

A good internal platform:

shortens time-to-value for builders
bakes in policy and auditability
reduces the cognitive load of doing the right thing
removes the need for humans to enforce every rule

This is the treaty. Not a meeting. Not a policy doc. A platform.

Steal this: Build a paved road, then enforce that prod traffic stays on it.

So What's the Actual Conclusion

Speed vs control does not end. It just changes form.

Enterprises that win do two things consistently:

They automate governance and move it into pipelines and platforms.
They centralise foundations while keeping teams autonomous at the app layer.

Speed without control produces fragile systems.

Control without speed produces irrelevant systems.

The mature answer is not compromise.

It is architecture.

The Future of Low-Code: Trends Shaping 2026–2030!

Nigel Tape — Fri, 23 Jan 2026 14:18:06 +0000

Low-code and no-code are no longer “a faster way to build dashboards.” They are becoming the operating layer for how organisations ship internal software, automate operations, and safely embed AI into workflows.

The next 5 years (2026–2030) are where the category continues to improve on its serious, governed software delivery.

Let’s anchor this in numbers.

1) The market is big, growing fast, and still fragmented

Different analysts measure different slices (pure low-code platforms vs low-code + digital process automation). That’s why ranges look wide.

Forrester frames the market more broadly, bundling low-code platforms with digital process automation (DPA). In that lens, it estimates the market was $13.2B by the end of 2023, with a base-case path to roughly $30B by 2028. Forrester also outlines an AI-fuelled upside scenario where the same combined market could reach around $50B by 2028.

Grand View Research narrows the definition to the low-code application development platform market specifically. Under that scope, it sizes the market at $6.78B in 2022 and forecasts growth to $35.22B by 2030, implying a 22.9% CAGR from 2023 to 2030.

Two takeaways for 2026–2030 planning:

Even the conservative paths show sustained growth through 2028 and beyond.
The category is converging with automation and AI, which is why “platform” matters more than “builder.”

2) What Will Actually Drive Adoption In Future

Driver A: AI becomes the default interface for building, but governance becomes the default requirement

Gartner’s forecast is blunt: by 2028, 75% of enterprise software engineers will use AI code assistants, up from <10% in early 2023 (and 63% of organisations were already piloting/deploying by Q3 2023).

That matters for low-code because it changes expectations:

Stakeholders will ask, “Why can’t the platform generate the first draft?”
Security teams will ask, “Where are the controls, audit trails, and approvals?”

Gartner is also blunt about the downside of ungoverned AI: over 40% of agentic AI projects will be cancelled by end of 2027 due to cost, unclear value, or inadequate risk controls.

Reuters coverage notes Gartner expects agentic AI to be in 33% of enterprise software by 2028 and to autonomously handle 15% of daily business decisions by 2028.

So the 2026–2030 era is not “AI everywhere.” It’s “AI in limited doses, with adult supervision.”

Driver B: Internal tools are where time (and money) quietly disappears

Internal software rarely fails loudly. It fails like a slow puncture: meeting-by-meeting, approval-by-approval, tool-by-tool. And newer research is finally putting numbers on that drag.

Developers don’t spend most of their week coding. Atlassian’s State of Developer Experience Report 2025 (survey with Wakefield Research; 3,500 developers and managers) highlights that developers spend around 16% of their time coding, meaning the bottleneck is the other 84% of the week: discovery, coordination, access, approvals, compliance steps, and operational grind.
Time lost is measurable and large. The same Atlassian research reports 50% of developers lose 10+ hours per week to non-coding work, and 90% lose 6+ hours or more, largely due to organizational inefficiencies (poor information access, fragmented tools, context switching).
Independent time-allocation research shows a similar shape. A Microsoft Research study on developers’ “actual vs. ideal” weeks found that, in the actual week, developers spent ≈12% on communication & meetings, ≈11% on coding, ≈9% on debugging, etc., while their “ideal” week shifts significantly more time toward building (e.g., ≈20% coding). It’s a quantitative view of the same problem: engineers want to build, but the system taxes them first.

That’s the economic engine behind low-code and no-code: not “developers can’t code,” but organizations can’t afford to waste senior engineering time on internal glue work.

Between 2026 and 2030, the winners won’t just accelerate UI assembly. They’ll compress the non-coding 84% without creating governance debt: secure connectivity, auditability, approvals, role-based access, and safe reuse across teams.

Driver C: The definition of “enterprise low-code” is shifting under your feet

Gartner’s description of enterprise low-code application platforms (LCAPs) highlights that they now include:

Full application lifecycle support across the stack (not just UI)
Security/governance capabilities
Increasingly AI-assisted development features

This is why “drag-and-drop” becomes table stakes. The differentiator becomes: can you build safely, integrate everywhere, ship repeatedly, and survive audits?

3) What Low-Code/No-Code Will Look Like Between 2026–2030 (Practical Forecast)

“Guardrails-first” becomes the buying criteria

AI pilots get cut aggressively if they do not show measurable value or risk controls.
Low-code platforms that behave like real software delivery systems (versioning, environments, approvals, auditability) get budget.
Platforms that feel like “prototype toys” get squeezed.

Procurement questions you will hear more:

Can we enforce RBAC and least privilege?
Can we audit who changed what and which data was accessed?
Can we keep data inside our VPC / self-hosted environment where needed?
Can we integrate with our identity layer and SDLC?

AI-assisted building is expected, but “agent washing” gets punished

AI code assistants become mainstream in engineering orgs.
Agentic features show up inside enterprise software, but many projects fail if they are not grounded in workflow orchestration and controls.

Platforms that combine:

workflow orchestration (clear steps, approvals, fallbacks), and
AI augmentation (drafting, summarising, routing, extracting), will outperform “autonomous magic” platforms.

Platforms consolidate, and the winner is the one that “ships boringly well”

By 2030, market projections still show strong growth in low-code platforms as a category.
But the story shifts from “anyone can build” to “everyone can deliver safely.”
This is where enterprise platforms with repeatable governance win the long game.

4) Why Retool, ToolJet and Appian Map Cleanly to This Future

Retool: “Internal tools tax reduction” with measurable developer-time framing

Retool’s research repeatedly quantifies the internal tooling burden (30% to 45% developer time, depending on company size). In a world where enterprises are trying to do more with smaller teams, that framing gets sharper, not weaker.

Why this matters:

Internal tool demand does not go away; it grows as operations become more software-driven.
The winners are the platforms that let teams build fast while staying governable.

ToolJet: “Control + Cost” for teams that want developer ergonomics along with business-user involvement

ToolJet positions itself as an open-source low-code platform focused on speed without sacrificing cost or control. The platform matches Retool feature by feature with a slight edge on AI capabilities.

ToolJet is trusted by companies like Orange, Swisscom, Toss, EDG, etc. These are enterprises that operate at scale and face demanding internal tooling requirements.

Why this matters:

When AI + governance concerns rise, “control” becomes a first-class requirement, not a preference.
Open-source and deployment flexibility can be a decisive advantage for regulated environments.
AI is shaping the future, and ToolJet leads the way with a first-mover advantage in enterprise-grade AI integration.

Appian: “Process automation at enterprise depth” when workflows need to survive audits

Appian plays in the heavier end of the spectrum: process automation, orchestration, and enterprise governance.

Why this matters:

As agentic AI gets embedded into business processes, controlled orchestration becomes the real differentiator (not just UI speed).
Regulated industries tend to standardise on platforms that look and behave like enterprise systems, especially under audit pressure.

5) The Unsexy Checklist That Will Decide Winners in the Next 5 Years

Governance

RBAC, audit logs, approvals, environment separation, change history, and predictable release processes.

AI that is safe-by-design

Given Gartner’s forecast that 40%+ agentic AI projects get cancelled by end 2027, AI features need measurable value and risk controls.

Integration reality

Databases + internal APIs matter more than “lots of SaaS connectors.” Retool’s internal tools research repeatedly shows how internal data sources dominate internal tooling.

Developer experience, not just citizen dev

Because by 2028, the majority of enterprise engineers are expected to use AI assistants, platforms must support engineers who want speed and control.

Cost and deployment flexibility

As the market grows (and budgets get scrutinised), platforms that offer better control over deployment and long-term cost tend to win standardisation debates. This is where open-source options like ToolJet are naturally well-positioned.

Closing: The 2026–2030 Bet

The next wave of low-code is not about replacing engineers. It’s about making every workflow shipable with:

AI assistance where it’s cheap and safe
orchestration where risk lives
governance everywhere

My bets are on:

Retool for organisations trying to claw back the 30%–45% internal tools time sink with a platform built around internal software velocity.
ToolJet for teams that want control, flexibility, enterprise-grade maturity, AI capabilities, and open-source leverage.
Appian for enterprises where process, governance, and auditability are the product.

A Practical Performance Comparison of Top Internal Tool Builders

Nigel Tape — Thu, 15 Jan 2026 10:54:45 +0000

1) Intro + Setup

A Solutions Architect with experience building (and breaking) enterprise systems eventually wants an answer to one simple question:

“Can this thing actually handle load without melting?”

That’s the real litmus test for any platform that claims it can handle complex, data-intensive internal tools.

So instead of doing another “Top 10 Low-Code Platforms of 2025” list, I narrowed it down to the ones that consistently feel fast:

Retool
ToolJet
Appsmith

DronaHQ appears later in this article, but there’s a reason it didn’t make the main list (you’ll see).

I’ve also intentionally left out legacy platforms like Appian and Mendix. They serve a purpose, but performance comparisons against modern, developer-first tools would be apples vs office furniture.

Now, let’s actually test them.

Disclaimer: Performance may vary based on your device, browser, and environment. These results reflect tests on a specific setup and should be treated as indicative, not absolute.

2) Test 1: The Raw JS Execution Benchmark (200,000 rows)

The idea was simple:

Create a JavaScript query on all three platforms.
Generate 200,000 rows of dummy “product data” (large enough to expose browser bottlenecks).
Measure how long the platform takes to return the data.

Results

Retool: ~508 ms

ToolJet: ~202 ms

Appsmith: Crashes instantly :-(

ToolJet had the fastest execution by a comfortable margin. Retool’s 500+ ms is not bad for that volume, just not best-in-class. Appsmith, unfortunately, didn’t survive the test at all. It froze before the table even had a chance to render.

If your use case includes dashboards with real-world API calls and moderately large data sets, the difference between 200 ms and 500 ms is not life-changing. But if you’re building complex applications with heavy client-side computation, it does add up.

Appsmith failing at the starting line was… not ideal.

3) Test 2: “Real App” Stress Test (50,000 rows + 10-page application)

Synthetic benchmarks are useful, but they don’t reflect the complexity of real internal tools.

So the next test was a stress test:

Build a complex app using each platform’s AI builder, then add more components.
Add a JS query returning 50,000 rows into a table.
Keep duplicating the initially created page to see how far the platform can take it.
See what breaks first.

We’re not checking how they handle complexity. We’re checking how they behave when things get absurdly complex. 🙂

Retool

I’ll say this upfront: Retool performs well for complex apps.

The first few pages with the 50k-row table behaved smoothly.

At around 10 pages, each with its own query-trigger confirmation (configured by me), Retool finally froze.

To be fair, this is well beyond what a normal enterprise app should do. No one is building 10 pages filled with 50k rows each. But as I mentioned earlier, we need an answer to:

“Can this thing actually handle load without melting?”

On a side note, something became very clear while trying to push Retool further after the AI-generated base app: having 150+ components in the library is not always an advantage. A large chunk of them are just minor variations of a main component. For example, instead of offering both a container and a collapsible container, you could simply have one container with a collapsible toggle. The result is more noise than choice, and for new users it creates confusion rather than capability.

Performance: Good.
Developer experience: Needs a map and a cup of tea.

ToolJet

Next up is ToolJet.

We follow the same process: create an app using ToolJet’s AI builder, add more components, and load it with a table of 50,000 rows of data.

ToolJet stayed as smooth as Retool, and interestingly, it felt like I could push further after the 10 page mark. The rendering pipeline and table handling seem slightly more forgiving under load. You can see the application’s 10th page in the screenshot below.

Again, nobody is building a monster app with 50k-row tables everywhere, so this is academic. But if you are dealing with long, multi-page workflows or heavy dashboards, that extra headroom helps.

Performance: Slightly better than Retool under extreme conditions.

Appsmith

Let’s check back on Appsmith.

It’s still frozen on the initial screen.

That’s the whole update.

4) Bonus Test: DronaHQ

I wasn’t planning to test DronaHQ. The dated UI didn’t give me much confidence, although I like some parts of the platform. But curiosity won.

I tried the same 200,000-row JS query. It returned 15 rows, clearly truncated. Not to be dramatic, but that seemed like a red flag.

I added a table and tried to preview the full data in a new tab. The platform crashed instantly.

Red flag number two… and three.

Performance: Disappointing.

I expected more here. Hopefully DronaHQ shows some meaningful improvement in future tests on other aspects of enterprise app building.

5) Final Verdict

Both Retool and ToolJet are fast. Both can handle very complex apps. Both passed every realistic benchmark.

Appsmith crashing at the very first step, and DronaHQ returning truncated data (and then crashing), didn’t inspire a lot of confidence.

If you’re choosing between Retool and ToolJet, performance should not stop you from picking either. They’re both enterprise-grade and fast.

ToolJet’s slight edge on query execution can be beneficial in extreme cases. But overall, both platforms perform well. For complex apps, you won’t go wrong with either.

What I’ve Learned About Enterprise Development in 15 Years

Nigel Tape — Mon, 20 Oct 2025 18:30:00 +0000

I started in enterprise development believing technology was the answer. Fifteen years later I know it’s rarely the first one. I’ve worked with hundreds of clients and built thousands of systems. The lessons are sharp. The stats are unforgiving.

Scale is overrated

Everyone talks “scale” as if it’s the end-game. In reality most enterprise systems struggle with clarity, not traffic. In public sector studies large IT projects averaged a 24 % schedule overrun, but 18 % were outliers with cost overruns >25 %. One study found cost overruns follow a power-law: most projects modestly overrun but a small number explode.

For enterprises the question should be “how simple can we keep this” rather than “how big can we make it.”

Process vs progress

Development frameworks proliferated. Agile, DevOps, SAFe became religious. Yet success did not follow. A whopping 66 % of software projects fail (in at least one dimension). Another source summarises: up to 70 % of digital-transformation efforts fail to meet targets.

These failures are not due to methodology alone. They stem from weak alignment, poor requirements, unclear ownership.

The human layer is architecture

Systems don’t collapse because the server failed. They collapse because the humans using them mis-communicated, because ownership was lacking, because politics overrode design. Research shows poor business-technology collaboration is a major factor in failed programmes.

In 15 years I’ve seen senior engineers leave not because the paycheck was low but because they couldn’t fix the political entanglements around tech.

Tool overload kills clarity

Every year brings a new “must-have” platform, a new framework, a new dev-ops chain. But tools don’t guarantee outcomes. Many tools are installed and then abandoned. According to project management data 42 % of organisations “don’t understand the need or importance of project management” and that correlates with higher failure rates.

In practice I found that the simplest stack with clear ownership out-lasts the most advanced architecture with no one driving it.

Data truths

“Single source of truth” is a marketing slogan, not a daily reality. Studies estimate that up to 68 % of available enterprise data goes unused. For analytics dashboards: one survey found 49 % of software projects exceeded budget and 31 % were cancelled entirely.

In enterprise terms: pipelines rot quietly. Data becomes stale. The system still runs, but the value doesn’t.

Security and compliance theatre

Enterprises love audits, checklists, certifications. But they often treat them as goals rather than enablers. One source noted that many companies feel their digital-transformation investment produced no performance or profitability increases.

I learned the hard way: true security starts with simple architecture, clear ownership, and minimal dependencies. Not a thicker audit binder.

Cloud isn’t magic

Move to the cloud, we were told, and complexity will disappear. The truth: complexity shifts. Multi-cloud sounds sexy but becomes a billing, governance and skills nightmare. I saw many “cloud-native” initiatives that still had cron-jobs on virtual machines, archaic patterns transplanted in new terrain.

The cloud is powerful but only when you simplify your architecture rather than replicate old complexity.

What actually works

In fifteen years I distilled what works into a few repeatable principles:

Small cross-functional teams with end-to-end ownership.
Define outcomes early. Do not proceed until you know what success looks like.
Build systems that survive bad choices, not prevent all mistakes. The design must accept that someone will misuse it.
Reduce dependencies. Complex ecosystems ruin agility.
Align technology delivery with business objectives. Tech for its own sake fails.
Continuous feedback. If after six months users aren’t adopting, shut it down or pivot.

Final lesson

In enterprise development survival is more valuable than every innovation. The goal is to build systems that survive the people who built them. Architecture isn’t about control. It’s about restraint. Keep it clear. Keep it owned. Keep it simple.

Forem: Nigel Tape

AI Coding Adoption at Enterprise Scale Is Harder Than Anyone Admits

AI Coding Adoption at Enterprise Scale Is Harder Than Anyone Admits

What the Market Gets Right

Where the Story Starts to Crack

Why Enterprises Slow the Rollout

The Trust Problem Is Larger Than the Adoption Story

The Rollout Mistake Most Companies Make

What a Realistic Enterprise Rollout Looks Like

Start with low-risk use cases

Define usage zones

Keep human gates intact

Measure outcomes that matter

Treat policy as part of the product

The Real KPI Is Not Lines of Code

My Forecast for the Next 12 to 24 Months

Final Thought

Read More

Enterprise App Builders That Are Actually Enterprise-Ready (Top 5)

What “Enterprise-Ready” Really Means in Practice

The Evidence Pack To Ask For (And Why Procurement Asks For It)

1) Appian

Enterprise proof points

Where Appian shines

2) Mendix (Siemens)

Enterprise proof points

Where Mendix shines

3) ToolJet

Enterprise proof points

Where ToolJet shines

4) Retool

Enterprise proof points

Where Retool shines

5) OutSystems

Enterprise proof points

Where OutSystems shines

A Quick “Choose Based On Your Reality” Guide

Where “Pure AI App Builders” Still Struggle In Enterprise

Final Takeaway

Speed vs Control: The Structural Conflict Inside Enterprise Application Development

Pattern 1: Move Control From People Into Systems

Example: Netflix

Pattern 2: Standardise the Substrate, Not the Product Teams

Example: Amazon

Pattern 3: Treat Production Readiness as a Product Requirement

Example: Google (SRE Model)

Pattern 4: Governance Shifts Left, but Not as Paperwork

Example: ING

Pattern 5: Decentralisation Without Coordination Creates Tool Sprawl

Example: Spotify

Pattern 6: Identity Becomes the Control Plane

Pattern 7: Observability Is Governance

Pattern 8: Platforms Create "Safe Speed"

So What's the Actual Conclusion

Read More on Enterprise Delivery, Platforms & Governance

The Future of Low-Code: Trends Shaping 2026–2030!

1) The market is big, growing fast, and still fragmented

2) What Will Actually Drive Adoption In Future

Driver A: AI becomes the default interface for building, but governance becomes the default requirement

Driver B: Internal tools are where time (and money) quietly disappears

Driver C: The definition of “enterprise low-code” is shifting under your feet

3) What Low-Code/No-Code Will Look Like Between 2026–2030 (Practical Forecast)

“Guardrails-first” becomes the buying criteria

AI-assisted building is expected, but “agent washing” gets punished

Platforms consolidate, and the winner is the one that “ships boringly well”

4) Why Retool, ToolJet and Appian Map Cleanly to This Future

Retool: “Internal tools tax reduction” with measurable developer-time framing

ToolJet: “Control + Cost” for teams that want developer ergonomics along with business-user involvement

Appian: “Process automation at enterprise depth” when workflows need to survive audits

5) The Unsexy Checklist That Will Decide Winners in the Next 5 Years

Governance

AI that is safe-by-design

Integration reality

Developer experience, not just citizen dev

Cost and deployment flexibility

Closing: The 2026–2030 Bet

A Practical Performance Comparison of Top Internal Tool Builders

1) Intro + Setup

2) Test 1: The Raw JS Execution Benchmark (200,000 rows)

Results