No code software falls into a handful of real categories — site and app builders, automation platforms, databases with a visual interface, form tools, and internal-tool builders — and every one of them, no matter how much code you never write, still runs on a database, a runtime, and a domain somewhere. The no-code part removes the syntax, not the infrastructure. Knowing which category a tool falls into tells you what it can actually do, and knowing what sits behind it tells you when the vendor’s own hosted plan is the easy choice and when running the tool yourself is the better one.
Listicles ranking the best no-code tools treat the category as one thing, which is why they read like a grab bag: a website builder next to a workflow automation tool next to a spreadsheet-database hybrid, ranked on the same scale. They solve different problems and hit different ceilings. This post sorts the categories out, then covers the part every one of them shares and nobody markets: the actual server, database, and domain running underneath the drag-and-drop interface.
Table of contents
- Site and app builders
- Automation platforms
- No-code databases and backends
- Forms and internal tools
- How to pick a category before picking a tool
- What still needs real infrastructure, no matter the category
- When self-hosting the tool wins
- How this fits the rest of the stack
- FAQ
Site and app builders
The category most people mean by no code: drag-and-drop interfaces that produce a website or a simple application, from landing-page builders to more capable app builders with basic logic and data binding.
The ceiling shows up around custom logic and scale — anything beyond forms, lists, and simple conditionals usually needs a plugin ecosystem or an escape hatch to custom code, and the builder’s hosting is bundled in, which is convenient until you want to move the site anywhere else.
Automation platforms
Tools that connect other services and move data between them on a trigger — a form submission creates a record, a new record sends a notification, and so on, without writing the glue code by hand.
The commercial hosted versions, task-based pricing, a visual flow editor, are genuinely fast to start with. The self-hosted alternative, n8n being the best-known open-source option, gives you the same visual workflow model without per-task billing, at the cost of running the server yourself, or on a managed platform that runs it for you. The no-code automation platform guide goes deeper on this specific category.
No-code databases and backends
Spreadsheet-like interfaces that behave more like a real database underneath — structured tables, relations, and often an auto-generated API, aimed at people who think in rows and columns rather than schemas.
These genuinely lower the bar for building something with real data behind it. The trade-off is the same one as any hosted database: your data lives in someone else’s system, migrating out later ranges from straightforward to painful depending on how proprietary the export format is, and query performance at scale is bounded by what the vendor exposes, not by what the underlying database could actually do.
Forms and internal tools
Forms are the simplest and most mature no-code category: a form that collects input and sends it somewhere, which sounds trivial until the somewhere has to be a database, a notification, and a workflow, not just an email.
Internal-tool builders are the more capable cousin: connect an existing database or API and generate an admin panel, a dashboard, or a small internal app without a frontend developer. This is where the phrase still needs infrastructure is most literal — the internal-tool builder is a UI layer sitting on top of a database and API that have to exist and stay up regardless of how the interface was built.
How to pick a category before picking a tool
Start from the category, not the tool. A landing page needs a site builder. A recurring task connecting two services needs automation. A dataset with relationships needs a no-code database, not a spreadsheet with formulas stretched past their design. An internal dashboard on top of data you already have needs an internal-tool builder, not a site builder pressed into service.
Picking the wrong category is the more common mistake than picking the wrong vendor within the right one — most vendors within a category are reasonably comparable; a site builder asked to do automation’s job, or vice versa, fails regardless of which specific one you chose.
What still needs real infrastructure, no matter the category
Every category above, at some point, needs a database to hold data, a runtime somewhere for anything that runs logic on a schedule or a trigger, and a domain and certificate if the result is public-facing. The no-code layer replaces the syntax for building the logic. It does not replace the server that runs it, the database that stores its state, or the domain that makes it reachable.
This is the gap that surprises people moving from a prototype built entirely in a no-code tool to something that needs to scale, integrate with an existing system, or simply cost less at volume — the infrastructure was always there, just owned by the vendor instead of by you.
When self-hosting the tool wins
For automation specifically, the calculation flips once volume gets real: a hosted automation platform billed per task or per execution can get expensive fast for a workflow that runs constantly, while the same workflow self-hosted has a flat cost regardless of how often it fires.
n8n is the clearest example — it is open source, and running it yourself removes per-execution billing entirely. On a managed platform, that means a create form and a plan rather than a server you patch: n8n on a $6 Basic plan, with a managed Postgres beside it for anything the workflow needs to persist, replaces both the vendor’s hosted pricing and the maintenance of self-hosting it on a VPS.
How this fits the rest of the stack
No code software is a real productivity gain for the part it actually replaces, writing the syntax, and it was never going to replace the database, the runtime, or the domain underneath. For the automation category specifically, where hosted pricing scales with usage, running the tool yourself on a managed plan is often the more predictable cost: managed n8n on RunxBuild runs as a create-form deployment rather than a server to patch. If you are weighing that against a vendor’s hosted pricing, the RunxBuild hosting calculator puts the plan and a managed database side by side, services on RunxBuild covers the deployment model, and the dashboard is where you would deploy it.
Useful related references:
- No Code Website Builders: Where the Ceiling Is and How to Tell You Hit It
- No-Code Automation Platform: Where the Automation Actually Runs
- Small Business Automation: Start With the Task You Do Every Tuesday
- Services on RunxBuild
FAQ
What are the main categories of no-code software?
Site and app builders, automation platforms, no-code databases, forms, and internal-tool builders. Each solves a different problem and hits a different ceiling, which is why ranking them all on one scale, as most listicles do, is not very useful for picking the right one.
Does a no-code app still need a database?
Yes. The no-code layer replaces the syntax for building logic, not the infrastructure underneath it. Every category, sooner or later, needs a database to hold data, a runtime for anything that runs on a schedule or trigger, and a domain if the result is public-facing.
What is the difference between no-code and low-code?
No-code aims to require zero custom code, using visual configuration for everything, including logic. Low-code covers the same ground but expects an escape hatch to real code for anything the visual layer cannot express, which usually means a higher ceiling and a steeper learning curve.
Can I self-host a no-code automation tool like n8n?
Yes, n8n is open source and can run on your own server or a managed platform. Self-hosting removes the per-execution billing that hosted automation platforms typically charge, which matters once a workflow runs constantly rather than occasionally. On a managed plan, it runs as a deployment with its own domain and logs rather than a server you patch yourself.
When should I stop using a no-code tool and build custom?
When the logic needed no longer fits the tool’s visual model, when data needs to move somewhere the tool’s export does not support cleanly, or when usage-based pricing on a hosted platform starts costing more than running the equivalent yourself. All three show up as the project matures, not on day one.