Why Internal Tools Are Still Too Hard to Build

Why Internal Tools Are Still Too Hard to Build

Building an internal dashboard for the operations team should not take three weeks. Spinning up an admin panel for support to manage customer accounts should not require a sprint, a JIRA ticket to DevOps, and a security review that runs four days. A microsite for an internal training programme should not sit on someone's backlog for two months because it is not a priority.

These are not fringe complaints. According to a survey of 500 IT and engineering leaders commissioned by Internal.io, engineering teams spend 40% of their time building and maintaining internal tools. Retool's annual research puts it at 33%, and that figure has risen every year. By either number, the scale of effort is enormous. What the numbers don't capture is how little of that time produces something that works well and keeps working.

This is the fourth post in a series examining why internal developer platforms fail to deliver on their promise. The first three covered why most IDPs recreate the queues they were meant to eliminate, why self-service infrastructure remains aspirational for most teams, and what IDP design should optimise for. This piece goes one layer upstream: before internal platforms fail, the tools that should run on them fail to get built at all.

The problem is structural, not resourcing

The standard diagnosis is that internal tooling is underfunded. That is true but incomplete. The deeper issue is that internal tools are treated as infrastructure costs rather than products. They get built by whoever had capacity during a slow sprint, handed off with minimal documentation, and maintained by nobody until something breaks.

Port.io's 2025 State of Internal Developer Portals found that only 15% of engineers have clarity on the standards they are expected to follow for internal tooling. That ambiguity is itself a signal: internal tools are built to solve immediate problems, not to a coherent standard. The result is a fragmented stack that engineers inherit rather than inherit from.

The voluntary adoption test raised earlier in this series applies here too. If the internal dashboard were optional tomorrow, would the operations team still use it? Usually the answer is: they'd build a spreadsheet instead. That is not commentary on the tool's quality. It reflects that the tool was built for the person who requested it, not maintained as a product for the people who use it every day.

The structural fix is straightforward to describe: treat internal tools as products. Give them owners. Schedule time to maintain them. Measure their usage and adoption. In practice, the organisational incentives point the other way. Internal tools do not generate revenue. They do not appear in product roadmaps. Engineering headcount spent on them is invisible to the business until something breaks publicly.

Deployment friction is different for internal tools

Public-facing applications get the full CI/CD treatment. Feature branches, preview environments, automated testing, staging gates, production deploys with rollback. The deployment pipeline for an internal admin panel, by contrast, might be a manual file copy to a shared server, a process documented nowhere, and a Slack message to the one engineer who knows the credentials.

Port.io's 2024 research found that 68% of organisations experience several weeks to months of lead time for internal app deployments. That figure would be unacceptable for any customer-facing product. For internal tools, it is treated as the cost of doing business.

The security posture is correspondingly weaker. Over 25% of respondents in Retool's 2022 survey said their internal tools have no access controls at all. Customer-facing applications would not survive a security review in that condition. Internal tools inherit a different standard, which creates a different kind of risk: one that compounds quietly until it surfaces in an audit or an incident.

The practical effect is a two-tier deployment culture inside the same organisation. Shipping a change to the customer-facing product follows an established, automated path. Shipping a change to the internal dashboard requires finding the right person, waiting for a window, and hoping nothing else breaks in the process. Developers learn this quickly and deprioritise internal tool work accordingly.

Why low-code didn't solve it

The market produced an obvious answer: no-code and low-code platforms. Retool, AppSmith, and others built developer-focused tools specifically for internal applications. The low-code market reached $30.1 billion in 2024. Internal tooling platforms raised substantial capital. Airplane.dev, a developer-native internal tools platform, raised $40.5 million and shut down in April 2024.

The market did not fail because the products were poor. It revealed that the problem is not tool selection. It is the structural conditions around internal tools that make them hard to maintain regardless of how they were built.

Low-code platforms carry their own friction. Analysis from Ten10 summarises the ceiling: low-code is a "trade-off for inflexibility" and is suited for "siloed, commonly repeated, similar tasks." When requirements expand — which they always do for anything actually useful — the tool becomes "a patchwork job of chaining systems together." Forty-seven percent of organisations in one survey cited poor scalability as a concern with low-code platforms, 37% cited vendor lock-in.

The internal tooling problem does not need a new category of software. It needs internal tools to be treated the same way public-facing products are treated: with deployment pipelines, clear ownership, and a path to iterate without filing a ticket.

What actually helps

The organisations that have improved this have typically done three things, none of which are novel.

Bring internal tools into the same deployment infrastructure as production apps. If spinning up a branch preview for an internal tool takes the same steps as spinning up a branch preview for the customer product, the tooling is no longer second-class. The deployment discipline follows the deployment path. Teams that give internal tools proper CI/CD pipelines see them improve and get maintained. Teams that leave internal tools on ad hoc deploy processes do not.

Give each internal tool a named owner. Not a team, not a Slack channel: a named engineer who is responsible for it. Ownership changes the relationship. A developer who owns a tool will document it, respond when something breaks, and push back when requirements expand beyond what the tool can sensibly handle. Shared ownership means no ownership in practice.

Make it possible to deploy something in an afternoon. The friction point is not the maintenance of internal tools that exist. It is the startup cost of internal tools that should exist but never get built because the path from idea to deployed thing is too long. When a developer can take a request from the operations team at 9am and have something deployed to a real environment by lunchtime, the nature of the problem changes. The tools get built because building them is not a project.

Forge's POV: internal tools deserve a real deployment path

The Forge developer platform applies the same git-driven, branch-preview deployment model to internal tools as to public sites. No ticket to request a staging environment. No separate process for internal versus external. A developer can push a branch and have a working preview URL to share with the ops team in minutes.

That is not a feature designed for internal tooling specifically. It is what happens when the deployment path is genuinely the same regardless of what is being deployed. Internal tools become as easy to iterate on as the product. The friction that keeps them underdeveloped disappears when deploying one is not a special case.

Most organisations do not need a platform strategy for internal tools. They need to stop treating internal tools as infrastructure and start deploying them like software.