What Using Superblocks Taught Me About the Rise of Self-Hosted Internal Tools

Over the last three years, I’ve spent most of my time building internal tools for teams with very different requirements.

Some projects were simple dashboards. Others started as small operational applications and gradually became systems that entire departments relied on every day.

One thing I’ve learned from that experience is that evaluating an internal tool platform is very different from living with it.

Most platforms look impressive during a proof of concept. They connect to databases, expose APIs, provide UI components, and help teams build applications quickly. The real differences tend to appear months later, when requirements start changing and the application becomes part of a team’s daily workflow.

One platform that helped me think about this differently was Superblocks.

I genuinely respect what the team has built. The product feels polished, the developer experience is strong, and it’s clearly designed for organizations that want a structured way to build internal software without maintaining everything themselves. For many teams, that’s exactly what makes it appealing.

At the same time, using it surfaced two friction points I’ve been thinking about ever since. They ultimately changed how I evaluate internal tool platforms entirely.

Internal Tools Are No Longer Just Internal Tools

A few years ago, most internal applications followed a familiar pattern. Teams built dashboards. Operations teams managed workflows. Support teams tracked tickets. Managers reviewed reports. The applications were important, but they generally sat on the edge of business operations.

That has changed.

Today, internal tools are increasingly becoming the connective layer between employees, systems, and data. The dashboard is no longer just displaying information. It’s triggering actions, coordinating approvals, pulling in AI-generated insights, and becoming part of how the business actually runs.

That evolution changes what teams need from their internal tooling platforms. The challenge is no longer building version one. The challenge is supporting versions five, ten, and twenty, in a way that holds up as the application becomes business-critical.

What Superblocks Gets Right

Before discussing what changed my perspective, it’s worth acknowledging what Superblocks does exceptionally well.

The platform provides a clean environment for building internal applications, connecting data sources, managing permissions, and shipping useful tools quickly. For organizations trying to move away from spreadsheets, manual processes, and fragile custom applications, that value is immediately obvious.

I also appreciate the emphasis on governance and structure. As internal tooling grows across multiple teams, consistency becomes increasingly important. Having guardrails around how applications are built, deployed, and managed can prevent a lot of operational headaches later.

The experience made me appreciate the value of managed platforms. It also made me think more carefully about two specific things: where your data actually goes when you run a “self-hosted” deployment, and what happens when your needs outgrow the built-in component library.

When “On-Premise” Doesn’t Mean What You Think

Superblocks offers an on-premises agent, a piece of software you install inside your own network that handles running queries against your internal data sources. For many teams, this is enough. But a project I worked on showed me where the model has a structural limit.

Friction moment 1 — The hybrid deployment boundary

I was working with a financial services team that had installed the Superblocks on-prem agent inside their network. Data queries stayed local, which was the requirement we had scoped against. What we hadn’t scoped against was everything else.

When the compliance team reviewed the setup before a security audit, they flagged it. Even with the on-prem agent in place, user authentication still routed through Superblocks’ servers. The applications themselves were served from Superblocks’ infrastructure. Audit logs and usage telemetry were forwarded to their cloud as well. The core of the platform lived entirely outside our walls.

This is Superblocks’ documented architecture, not a flaw. Their on-prem agent handles data queries, but the platform’s management layer runs in Superblocks’ cloud. Compliance saw a system where operational data was touching a third-party cloud environment not covered by their data handling agreements, and that became a weeks-long blocker requiring significant rework.

By the time it became a real constraint, the application was already in production.

The lesson wasn’t that Superblocks had misled us. The architecture is clearly documented. The lesson was that “on-premise agent” and “fully self-hosted” are not the same thing, and the difference only becomes material when compliance or data residency requirements enter the picture. For business-critical applications, they usually do, eventually.

What I needed was a platform where everything, the authentication, the workflow logic, the app itself, could live inside my own infrastructure. Not just the database queries.

The Customization Wall That Appears Later

The second friction point was less about infrastructure and more about what happens when your needs outgrow the built-in component library. Every internal tool platform has one. The question is how gracefully you can step outside it.

Friction moment 2 — Custom components outside the platform’s reach

I needed a data table with specific behaviors for a customer operations tool: the ability to edit rows directly in the table, select multiple rows and take bulk actions, and display one column in a custom format that didn’t exist as a built-in option. The native table component covered maybe seventy percent of what was needed.

Superblocks does support custom components, but building them requires a separate workflow outside the app builder entirely. You write the code on your own machine, package it up, publish it through a command-line tool, then import it into the app. And once the component is running, it’s largely isolated from the rest of the application. Getting it to share data with other parts of the tool, or to trigger actions elsewhere in the app, requires extra wiring that isn’t always straightforward.

In practice: change the component, repackage, republish, reimport, test. Each cycle added twenty to thirty minutes of overhead. And because the component sat somewhat apart from the platform’s own state management, small bugs were hard to trace. After a few weeks, the component felt like a separate project that happened to live inside the tool.

This is a solvable problem on Superblocks, and teams do build sophisticated custom components. But the friction was real, and it made me think about what it would look like if custom components were a first-class part of the builder rather than an extension bolted on from outside.

Why Deployment Control Matters More in the AI Era

Both of these friction points became more significant as AI started entering internal tooling discussions. A few years ago, most internal applications I worked on focused on dashboards and workflow automation. Today, teams increasingly want AI assistants built into their tools, automated summaries, AI-generated reports, and workflows that connect employees directly to their organization’s data and systems.

As soon as AI enters the picture, where your platform runs and how flexible it is start to matter a great deal more. Teams start asking: Where is data being processed when an AI workflow runs? Who can see it? How do we track what the AI did? How do we build interfaces that go beyond the standard options?

The internal tool is no longer just an application. It’s a coordination layer between employees, business systems, proprietary data, and AI services. Where that layer runs, and how extensible it is, starts to matter enormously.

The Broader Shift Toward Infrastructure Ownership

What I’ve found most interesting is that this conversation extends far beyond any individual platform. Across the industry, more teams are evaluating internal tooling through the lens of ownership and control rather than purely development speed.

AI adoption is one reason. Compliance requirements are another. Data residency concerns matter for some organizations; flexibility for others. Whatever the reason, the question of where your platform runs is moving closer to the center of these decisions.

The question is no longer just “How quickly can we build this?” It’s increasingly “How much control will we need once this becomes critical?” That’s a fundamentally different way to evaluate a platform.

What I’ve Been Using Instead

The two friction points I hit with Superblocks led me toward platforms that resolve them by design rather than through workarounds. ToolJet, in particular, addresses both directly.

On deployment: ToolJet runs entirely inside your own infrastructure. There’s no external management layer to connect to. Authentication, workflow logic, app definitions, and data queries all run where you put them, whether that’s your own servers, a private cloud, or a fully air-gapped environment with no internet connection. A compliance team reviewing the setup sees a system that lives entirely within their own walls, with no external dependency to negotiate around.

On customization: ToolJet’s custom component model works differently. You write custom components as code directly inside the app builder, with no separate packaging or publishing step. Through a simple data-passing interface, the component can read values from the app, update its own data that other parts of the app can reference, and trigger any query by name. It’s not magic — you still wire up what the component needs — but it all happens inside the builder, and the feedback loop collapses to change something, see it, rather than change, package, publish, import, test.

It’s also fully open source, with all its code publicly available on GitHub. For regulated industries where being able to inspect and verify the software you’re running matters for compliance, that’s not a nice-to-have.

None of this means ToolJet is the right choice for every team. Managed platforms like Superblocks remain genuinely strong for organizations that prioritize fast adoption and don’t face the infrastructure or customization constraints I ran into. The right platform depends on where your applications are heading, not just where they start.

Final Thoughts

My takeaway isn’t that Superblocks is the wrong choice. I still think it’s a strong platform and a good fit for many teams.

What those two friction moments clarified for me was that “on-premise agent” and “fully self-hosted” mean different things, and that custom component support varies a lot in how well it integrates with the rest of the platform. These aren’t things you discover during a proof of concept. They show up once the application is in production and requirements have grown beyond what was originally scoped.

As internal tools become more deeply embedded in business operations, and as AI workflows, compliance requirements, and customization demands grow alongside them, the gap between platforms that offer true ownership and those that offer a managed approximation is likely to widen.

That’s the shift I’ve been watching. And it’s one I expect to keep watching for a while.

Written from three years of forward deployed engineering work across fintech, operations, and enterprise internal tooling.