AwaitIO vs Superblocks: the full comparison
Last updated October 25, 2026
What is Superblocks?
Superblocks is a commercial platform for internal tools. It covers three things: internal apps, workflows and scheduled jobs.
You build an app in Superblocks’ editor. You place components, connect them to your databases and APIs, and add code where the editor is not enough. Superblocks calls this “extend anything with code”.
Workflows run a series of steps when something calls them. Scheduled jobs run the same kind of steps on a timer.
The platform is aimed at enterprises. It comes with role-based access control, single sign-on, audit logs, secrets management and GitOps deploys.
Today Superblocks is also pitched with AI app generation: you describe an app and AI builds it for you.
What is AwaitIO?
AwaitIO is a framework for internal tools written as code. An action is an async TypeScript function in your own repo.
Every await io.input call asks a person for something and waits for the answer. The browser shows the form, the person fills it in, and your function goes on with the value.
The same Node process that runs your app serves the UI. There is no separate platform to sign up for and no editor to log in to.
AwaitIO ships more than 20 components: 8 inputs, 3 selects including a table, 8 displays, a confirm and a layout. Anything missing is one React file you register next to them.
Key differences
Both tools give your team buttons and forms on top of your data. Superblocks starts from an editor and lets you add code. AwaitIO starts from code and has no editor at all.
Low-code with code, or just code
Superblocks is low-code first. The screen, the data connections and the steps live in its editor. Code is how you fill the gaps.
AwaitIO has no editor to fill. The whole tool is a function. await io.input.email() asks for an email. await io.select.table() lets a person pick rows. The screens follow from the code.
A tool in AwaitIO reads top to bottom like a script. Branches, loops and error handling are plain TypeScript, not blocks wired together.
Getting started
With Superblocks you create an account on the platform, connect your integrations and start building in its editor.
With AwaitIO you install the awaitio package from npm into the app you already have. You pass it a folder of actions.
Every file in that folder becomes an action, and its path becomes the URL. Folders become the navigation. There is no route table to keep in sync.
The first tool is one file with one await. It is running before you would have finished connecting a data source.
One tool, step by step
Say support needs to refund an order. Your team opens Refund order in the browser and sees a form with one field: Order ID.
In AwaitIO that form is one line, await io.input.text(). The function then loads the order with your own database client.
It shows the order with a display component and asks for a confirmation. Then it calls the refund service your app already has.
In Superblocks the same tool is a screen with a text field, a query, a table, a button and the wiring between them, built in its editor.
Both work. The AwaitIO version is one short function that any developer on the team can read and review.
Where the tool lives
A Superblocks app lives on the Superblocks platform. GitOps deploys move it between environments, but you still build it in Superblocks’ editor.
An AwaitIO action is a file in your repo. It goes through the same code review as the rest of the app. The TypeScript compiler checks it. Its history is in git.
When you rename a field in your database, the compiler points at every tool that uses it. Nothing breaks quietly on another platform.
Your data and your services
Superblocks reaches your data through integrations: database connections and API endpoints you set up on the platform. Logic that already exists in your app is often written again in its steps.
An AwaitIO handler runs in your own process. It imports your Prisma client, your services and your utilities and calls them directly.
Environment variables, secrets and network access work as they already do for your app. There is nothing extra to grant.
Extending the UI
In Superblocks the UI is built from Superblocks’ components in its editor. Custom components and styling take extra setup next to the editor.
In AwaitIO the whole UI stays in code. A component of your own is one React file with its props and the value it returns. You register it next to the built-in ones and await it like any io method.
The look comes from a theme package, @awaitio/theme-default, which you can restyle. The page around the components comes from a layout component, @awaitio/layout-basic, which you can replace with your own.
You never leave your editor.
Hosting
Superblocks is a platform you sign up for. It can keep your data inside your own network, but the apps are built and managed on Superblocks.
AwaitIO always runs inside your own Node app, on your own servers. There is no platform in between.
Nothing can be switched off from outside.
Access, audit and security
Superblocks sells to enterprises. Role-based access control, single sign-on and audit logs are part of the platform.
AwaitIO keeps this simple. The people who can log in are listed in code, each with an email and a password hash.
Every action knows who started it through ctx.user. Anything more, such as checks by role, is plain TypeScript in your handler.
Price model
Superblocks is a commercial platform with plans for enterprises. The details are on its pricing page.
AwaitIO is free for small teams, commercial use included. Above that it is one flat monthly price per organization, not per seat.
Free or paid, it is the same software. The details are on the pricing page.
Where Superblocks is stronger
People who do not write code can build in Superblocks. AwaitIO is for developers only.
Superblocks has workflows and scheduled jobs on the same platform. AwaitIO runs actions that a person starts in the browser.
Superblocks comes with enterprise access control, single sign-on and audit logs out of the box.
Superblocks can generate an app from a plain-text description. In AwaitIO a developer writes the code.
Who should choose which
Choose Superblocks if you want one enterprise platform for apps, workflows and scheduled jobs. It also fits when part of the team builds without code, or when security wants SSO and audit logs from one vendor.
Choose AwaitIO if a developer writes the tool. You get it in your repo, reviewed and typed like the rest of the app, running in your own process.
Many teams that pick AwaitIO used to write a CLI script or a SQL query and run it for support themselves. AwaitIO turns that script into a tool anyone on the team can run in the browser.
Moving from Superblocks to AwaitIO
Start with one app that a developer already maintains. Write its steps as one action: the inputs it asks for, the calls it makes and what it shows at the end.
Replace the Superblocks integrations with your own database client and services. The action runs next to your API, so it can reuse the code your app already has.
Move the code you wrote inside Superblocks into the handler. It becomes plain TypeScript with types, tests and review.
Use ctx.loading to show progress when the action goes through a long list.
Register the action, open the AwaitIO UI from your own server and send the link to the team. Move the next app when the first one works.
Workflows and scheduled jobs are a different job. Keep them where they run today, or move them to the job runner your app already uses.
Side by side
Write an async TypeScript function. Every await io.input call asks a person and waits for the answer.
Build in its low-code editor, extend with code, or generate with AI.
Inside your own Node app, on your own servers.
On the Superblocks platform.
In your repo, with code review, types and git history.
On the Superblocks platform, deployed with GitOps.
Comes from the code. Your own Node process serves it.
Built in its low-code editor.
No. The source code is public. The terms are on the pricing page.
No, commercial.
FAQ
Is AwaitIO a Superblocks alternative?
Yes, for teams where developers build the internal apps. AwaitIO replaces the low-code editor with TypeScript functions in your own repo.
Can people who do not code build tools in AwaitIO?
No. Every AwaitIO tool is written in code by a developer. Once it exists, anyone on the team can run it in the browser.
Can I self-host AwaitIO?
AwaitIO always runs inside your own Node app, on your own servers. There is no hosted platform to sign up for.
Does AwaitIO have SSO and audit logs like Superblocks?
No. The people who can log in are listed in code with an email and a password hash. Each action knows who started it through ctx.user.
Does AwaitIO run scheduled jobs?
No. AwaitIO runs actions that a person starts in the browser. Scheduled jobs stay with the job runner your app already uses.
Does AwaitIO charge per seat?
No. It is free for small teams and one flat monthly price per organization above that. The pricing page has the details.
Can I use AwaitIO and Superblocks together?
Yes. They do not depend on each other. Some teams keep Superblocks for workflows and low-code apps and write developer-owned tools in AwaitIO.