Superblocks

My company recently adopted Superblocks  three or four months ago. I work in a Cloud Infrastructure team, and our primary use for Superblocks  is building internal operations tooling, dashboards, workflows, and access management interfaces. Everything we previously had to build from scratch or manage through a patchwork of scripts and manual processes is now streamlined. Rather than standing up a full backend and frontend application for every internal need, our team uses Superblocks to rapidly connect to existing data sources such as databases, APIs, and cloud services, and then expose control interfaces. This means engineers spend time on complex infrastructure problems rather than building and maintaining internal scaffolding.

The three most prominent use case categories are access and permission management, where we request any access in a structured and auditable way. The second category is operational workflows, such as multi-step execution flows tied to human interactions. The third category is infrastructure monitoring and control panels, which are read/write dashboards connected directly to internal APIs and databases.

For example, we are using Superblocks for admin access requests. When an engineer or any external team needs admin-level access on a cloud resource or service, they submit a request through a Superblocks-built form. The form captures the requestor, resource, justification, and duration. The request is routed to the right approver, logged to the audit database, and it initially creates a Jira  ticket as well. Upon approval, it triggers an automated provisioning action via API. All of the form routing logic, approvals, and audit trail lives inside one Superblocks app. Earlier, the old process involved a Jira  ticket, manual Slack approvals, and a spreadsheet audit log. With Superblocks, the full workflow submission, routing, approval, provisioning, audit, and deleting the access after twelve hours was built in under a week. The role-based access layer ensures requestors only see their own requests and nothing else.

We used to use Jenkins  as a UI for engineers or other teams to raise a form or request any access. If anyone from the outside wanted to create a CNAME in any of the Route 53  zones, we had a Jenkins  job for that. They had to fill out the entire form in Jenkins and trigger the job. Since we do not find Jenkins good because it is time-consuming to build anything on Jenkins, we started using Superblocks for that part. I am currently working on a framework on Superblocks where users can perform CRUD functionality of Route 53 . Users can create Route 53 zones, either public or private. They can delete or add any record within a Route 53 zone, obviously after a cloud infrastructure engineer approves it.

The most valuable aspect of Superblocks is the combination of speed and flexibility. The key drivers are developer-grade code access. Unlike pure no-code tools, engineers can write full JavaScript logic inline, which is critical for infrastructure workflows that involve conditional logic, API chaining, and data transformation.

The second thing is built-in role-based access control and audit logging. Every action from a Superblocks app can be scoped by role and logged. This is non-negotiable for internal tools that touch privileged access or production resources. Native  database and API calls, direct connection to PostgreSQL , SQL, internal REST APIs, and any cloud provider API means the team is not copying-pasting data or building middleware layers just to surface information.

The UI can be built from Clerk AI within minutes.

The UI is good in most cases, but several friction points have emerged through real-world usage that require workarounds. The pain points are UI customization ceiling. When the team needs non-standard UI patterns, custom layouts, conditional forms, sections, and dynamic component trees, the visual builder becomes a constraint. Workarounds using custom HTML and CSS components are possible but slow and very fragile. There is no structured way to write unit tests for Superblocks logic. Debugging  complex JavaScript flows inside the builder is cumbersome compared to a proper IDE  environment.

Another pain point is documentation and error messages. When an integration fails due to API connection issues or permission errors, the error message surfaced in the builder is often opaque, increasing the debugging time.

Superblocks also lacks performance under complexity. Applications with many nested components, large data sets, or high-frequency refresh requirements show noticeable rendering lag. For an infrastructure dashboard displaying live metrics across dozens of resources, this is a real limitation. We have hundreds of AWS  accounts, and when someone views the VPN topology or VPC topology of some of the AWS  accounts, we see lag issues.

Superblocks is quite stable. I do not see any issues while building anything until now, except when working with large and heavy data sets, which we have just tested.

Superblocks' scalability is nuanced. It scales well for our team's current internal tooling workflows but has identifiable ceilings that would become blockers if usage changed significantly. Regarding user scale, hundreds of internal teams scale well, but it is not designed for thousands of simultaneous users. This is not a concern for the cloud infrastructure team, as of now. The second thing is application complexity. Performance degrades noticeably as the app grows in component count and data complexity. We have a C3PO workflow in the cloud infrastructure team, which took us four days because from C3PO, we built the AWS account from scratch to connect with the AWS accounts. When we are using it for C3PO, processing that one request is approaching the upper boundary of what can be done smoothly.

Superblocks is scalable enough for the cloud infrastructure team's current and near-term needs, but the team should avoid building deeply complex, high-traffic, or mission-critical workflows on it without a migration plan for the complexity and performance ceilings.

Be intentional about what you are building in Superblocks versus custom. Superblocks is excellent for building internal tools with standard functionality. If a tool requires deeply custom hooks, high-frequency real-time updates, or complex frontend state management, the cost of adding the platform quickly exceeds the cost of building it properly. You should draw a clear line before you start building.

Invest in access architecture up front. The role-based access system in Superblocks is powerful, but it requires deliberate design. A team that skipped proper role and permission planning at the start ends up having to delete everything and start again. Maintaining access structures for infrastructure tools, where security concerns determine who can see what, is non-negotiable.

For example, the first version of the admin access request tool was built quickly without formal role design. When audit requirements surfaced, the team had to retrofit the permission model, which was a painful rebuild from scratch. Now, we define the role requirements as the first step of any new Superblocks app before a single component is placed.

Another thing to consider is the testing and debugging experience. There is no structured way to write unit tests for Superblocks logic. Debugging  complex JavaScript flows inside the builder is cumbersome compared to a proper IDE  environment. My overall rating for this product is eight point five out of ten.

Public Cloud

Amazon Web Services (AWS)

What do you like best about the product?

Very easy to use, Intuitive and does the work we want to get done really well.

What do you dislike about the product?

There are small bugs here and there but nothing in particular

What problems is the product solving and how is that benefiting you?

We are able to create our admin tool with ease with out overhead of development time. There is a bit of learning curve but it is well worth it

What do you like best about the product?

I've used Superblocks in conjunction with Supabase for a project for a non-profit association for membership data management. I've used several other no/low-code platforms before and Superblocks arguably brings together the best combination of functionality, granular control when needed and documentation. The development and deployment control are generally well thought through and integration with source control. The Workflow functionality is powerful; in our case, it's being used to transpose old SOAP/XML API of a legacy membership service into more flexible REST ones. Support for Python alongside JS is also a differentiator.

What do you dislike about the product?

There are a few IDE quirks, though manageable, when trying to expand windows or identifying which API is currently being edited (not enough characters to see full name at times in fields/menu). The built AI agent in the IDE can at times be a bit too intrusive and an accidental keystroke to accept suggestions can lead to some unwanted code... That's more of a getting used to thing though.

What problems is the product solving and how is that benefiting you?

Providing volunteers of a non-profit organization a visual, online tool to manage membership data and annual directory preparation. Prior method involved multiple manual steps: exporting raw data from legacy system, staging MYSQL platform, running through complex SQL scripts for data transformation, exporting to several Excel sheets, then manually sifting through to correct address formats and other field data. And all these manual corrections would not flow back into the legacy platform by virtue of its old, legacy SOAP/XML based API. With Superblock and Supabase as a DB platform, volunteers can now work in an integrated UI platform, pull legacy data, see all the needed corrections following an automated data compliance review, and directly export the resulting dataset in Google Sheets, ready for insertion in the final annual membership directory preparation. This should provide a significant timesaver on these yearly cycles.

What do you like best about the product?

The low code feature speeds up my development process. Allows us to develop and use private data in an internal secure network environment.

What do you dislike about the product?

Hope to have more and richer components, improve the customization of components, and support more integrations.

What problems is the product solving and how is that benefiting you?

Secure internal environment, very timely and helpful technical support, rich components

What do you like best about the product?

Very small learning curve in comparison to other tools like Retool, takes very short time to setup and connect to the database with ease.

What do you dislike about the product?

Sometimes it's buggy and slow, the experience at times can be worse than with Retool.

What problems is the product solving and how is that benefiting you?

Lack of in-house engineers to develop custom admin panel