Superblocks Reviews

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.

My main use case for Superblocks is designing and modernizing one application. I am mainly using it to build the front end and the database part.

I used Superblocks during a legacy application modernization project to build internal tools and workflows that streamlined the operational processes. I worked on connecting the UI with the backend APIs and databases, implementing the business logic, and improving how users would interact with the legacy systems. This helped us reduce manual effort and made internal workflows more efficient.

Superblocks has impacted our organization and my team in significant ways. The time and effort were saved, almost halved, and we were able to build the interfaces and integrate existing APIs more efficiently. We could focus more on business logic rather than developing every internal tool from scratch. It also made it easier to expose the existing system functionality through a more user-friendly interface, which had the potential to improve user experience and simplify day-to-day operations.

Superblocks helped reduce the amount of repetitive UI development. Traditionally, building an internal application from scratch requires developing the front end, wiring up the APIs, entering data states, and implementing the necessary interactions. With Superblocks, we could configure many of those elements directly and connect them to the existing APIs, which shortened the development process. The biggest benefit was delivering internal tools without rebuilding functionality that already existed in our backend systems.

The best features Superblocks offers are that it is truly user-friendly. The user interface is beginner-friendly, and the commands, understanding, and context understanding of Superblocks are worth trying. The drag-and-drop UI builder, the screenshot builder, the database, and API integration were smooth. Workflow automation was smooth, and we were also able to customize the code execution.

For our legacy application modernization project, we were mainly focusing on the API integration, which made the biggest difference for my team. Since we were working on modernizing a legacy application, we needed a way to connect the existing backend system and data sources with a more modern interface without having to rebuild everything from scratch. Superblocks made it easier to connect APIs and data sources to the UI components, which helped us build internal tools more quickly.

It also allowed us to focus on the application logic and user experience rather than spending much time building repetitive front-end components. What stood out to me was the ability to build on top of existing systems while modernizing the way users interacted with them.

Another feature I found valuable was the flexibility to combine visual development with custom business logic. While Superblocks helped us speed up UI development and API integrations, it also allowed us to handle more specific requirements without being limited to a purely low-code approach.

One area where I think Superblocks could improve is debugging and troubleshooting complex workflows. While the visual builder makes development faster, when an application involves multiple API calls, database queries, and tracing the issue across the entire workflow can become challenging. I would also like to see more flexibility in customizing UI components and managing complex application logic as the project grows.

Low-code tools are great for accelerating development, but large applications still need maintainable code, clear separation of concerns, and better visibility into dependencies. Additionally, improvements to version controlling, change reviews, and debugging across development would be beneficial.

I have been using Superblocks for approximately one year.

Superblocks is quite stable to some extent.

As far as we are using it in the organization, it is quite good. We are yet to develop the complex parts, or I can say we have just started with the complex issues in our application, so time will tell.

The customer support is very friendly. I remember my manager approaching the customer support for some token issues which we were facing, and they were really helpful.

Previously, we were using Cursor AI, and we switched because we had one trial with Superblocks and the context understanding and project development with Superblocks was quite easier for us, and it was building the whole application in one place. That was the reason we switched.

I think the ROI is good. I can comment on the time part because the time, the tokens we are using, and the money we are paying to use Superblocks are actually giving high returns on the time we are saving. Our developers, including me, could focus more on the building part or designing part rather than developing the logic. The ROI is quite great.

We evaluated using or continuing with Cursor AI, or we had Cloud Kuda as well, and initially, we were using GitHub Copilot, but for modernization, we finalized Superblocks.

I would rate Superblocks a seven because the type of issues it resolved for me and the type of repetitive work it saved for my team is really outstanding, and we were able to focus more and deliver more in a short span of time. I couldn't score higher because I still expect the AI, the Clark AI it has, to work more efficiently and to understand complex issues in a better way because I have encountered issues where the Clark AI was not able to understand what I was trying to say.

I think governance and security are particularly important when introducing AI into enterprise applications. Superblocks's approach to centralize access control, integration management, and audit logging is valuable because it helps the team maintain visibility and control over how the application interacts with existing business systems. One area I would particularly attend to is ensuring that AI-generated code and workflows are properly validated before deployment. AI can accelerate development, but it can also introduce incorrect logic and security vulnerabilities. Human review, testing, and a clear approval process still remain essential.

Regarding reliability, I think it was pretty much what we required. As long as it was regarding UI development, we were optimizing the code and we were optimizing token utilization as well. I was majorly giving text commands and saving the screenshot commands to optimize the tokens. For the UI part, Superblocks's AI capabilities are outstanding, but when it comes to API handling and database, I think it was somehow able to satisfy the requirements, but there is still room for improvement in that.

Superblocks is a gigantic tool and I would say that what we are following is be very optimized with the AI and be very clear and distinct in your demands and your requirements to the Clark AI because it needs certain training to understand your project's requirements.

My main use case for Superblocks was to create CRUD applications, specifically focusing on making it a universal CRUD application given that the UI was very suitable at that time. Superblocks now supports a lot of other UI features and allows building using their own AI, Clark, but I was primarily focused on CRUD application building initially.

When I built those CRUD applications, we developed them for certain teams who were managing data manually using Excel sheets, which made their review process very tough. Our solution provided role-based access for managers to review, edit, and perform other tasks, thereby easing the manual reviewing and sharing of Excel documents for two or three teams involved.

Superblocks helps with quick prototyping and provides a good enterprise structure with a user-friendly UI, which is beneficial for business teams that are accustomed to working with Excel and similar applications, allowing for rapid creation of UI prototypes and application prototypes.

I think there was definitely a couple of hours' improvement since the teams were previously managing many Excel documents manually, and the CRUD applications helped streamline their review processes, resulting in significant efficiency gains.

The best features Superblocks offers include high-quality UI components and the Clark AI agent, which enables fast-speed prototyping and beneficial configurations for initial prototypes and large applications needing easy integration with various databases.

Among the features I mentioned earlier, I believe that UI quality, easy configuration, and connectors had the biggest impact on my workflow, as the UI configuration made creating quick prototypes straightforward and connecting with databases was simple and easy to manage.

In terms of improvements, I would suggest that Superblocks could enhance backend integrations and provide clearer visual understanding of components, though I have not worked with the latest version 3.0 that includes the Clark AI agent.

Overall, I feel the documentation support seems good, although I'm not sure about costs or anything else since I have not been involved in those discussions.

I chose a six out of ten because, while the UI components and quality are good, the backend presents challenges and there are some limitations including fewer options and less optimal animations that could improve usability.

I used Superblocks for a couple of months only, and although not very frequently, I utilized it when Superblocks was newly introduced into our company to do some prototyping and to understand how to build things there.

In my experience, Superblocks is stable with no reported downtime or crashes.

I believe Superblocks can scale to handle growing workloads and additional users, and while I have not practically witnessed it, I have seen a few users utilize the Clark AI agent efficiently.

Customer support experiences I heard of indicate that it is helpful and resolves issues effectively.

Based on hearsay, I would rate customer support eight out of ten.

I do not have specific metrics regarding return on investment, but a data engineer who typically builds APIs was able to create a CRUD app efficiently, which was a good achievement with minimal support.

I would rate Superblocks a six out of ten, or 6.5; six seems fair given my experience.

Although I have not been involved much in governance and security, I believe Superblocks has a good governance and security framework as they claim.

We have had limited experience with Superblocks's accuracy and reliability of output; while it performs well in prototyping, we have not built any large-scale applications as yet.

My recommendation to others reading reviews on PeerSpot is to evaluate your options carefully, particularly if you have a non-technical team seeking to build applications quickly and without coding. However, if your needs are for more dynamic websites with complex features, I might not recommend Superblocks and suggest considering the cost-to-value ratio seriously.