Internal Tools or Client Portals: The Shape Decides the Tool

Almost every regretted no-code decision has the same origin. Somebody evaluated the platforms on capability, picked the one that could do the most, and only afterwards discovered that its pricing model was designed for a fundamentally different kind of application from theirs.

The fix is to describe your app in one sentence before you look at a single feature list. Almost everything on our best no-code app builders list falls into four shapes, and the shape tells you which meter you want.

Shape one: the internal tool

A small group of colleagues, all of whom you employ or contract, using software that records what happened. A dispatch board. A stock count. A maintenance log. An approvals queue.

The defining characteristics are that the user count is small and known, and that writing is the point. Nobody opens a maintenance log to admire it; they open it to add a line.

That combination is difficult for a meter that counts changed rows, because changed rows are the entire purpose. It is comfortable for a meter that counts people, because there are few of them. And it is comfortable for a meter that counts published apps, because one app serving nine colleagues costs the same as one app serving nine thousand.

If your internal tool is also genuinely complex — branching approvals, calculated eligibility, rules with exceptions — then workload-metered Bubble becomes the honest answer, and the meter becomes a thing to manage rather than avoid.

Shape two: the client portal

An outward-facing application where each customer, supplier or member signs in and sees only their own material. Documents, order status, requests, invoices, project progress.

The defining characteristics are that the audience is external but countable, and that permissions are the hard part. The interface is usually simple; deciding who can see which row is not.

This is the shape per-user pricing was invented for. You know how many clients you have, you can name them, and the meter tracks the thing your business already tracks. It is also the shape where the data usually already exists somewhere — in a CRM, a spreadsheet, a database — which makes a front-end-only platform the natural fit rather than a compromise.

The trap is the plan step. Portals grow one client at a time, and per-user plans step in jumps; the boundary arithmetic is in what an app user costs on Softr.

Shape three: the field app

People away from a desk, on a phone, frequently with bad connectivity, capturing something. Inspections, deliveries, site reports, stock movements.

The defining characteristics are mobile-first and write-heavy, and it is the shape that most often has a genuine requirement to be a real installed application rather than a web page with a bookmark.

Ask one question honestly here: does it need to be in the App Store, or does it need to be on a phone? Those sound alike and cost very differently. If a responsive web app reached by URL would do — and for most internal field work it would — the shortlist stays open. If a store listing is genuinely required, the shortlist collapses to the one platform here that publishes to Apple and Google, which is covered in the Adalo review.

The write-heavy part matters too. A field app generating hundreds of records a week is the worst possible fit for a meter that charges per changed row against an external source.

Shape four: the public product

Anything anybody can sign up for. A marketplace, a community, a consumer utility, a booking service.

The defining characteristics are that the audience is unbounded and that success increases cost under most of these meters.

Per-user pricing is simply the wrong instrument here; you cannot commit to an unknown number of heads. Usage pricing is viable but converts every marketing win into a finance question. A flat published-app fee is the friendliest arrangement — and it comes attached to the lowest capability ceiling in the group, which is a trade rather than a free lunch.

This is also the shape where the export question stops being theoretical, because a public product that works is the most valuable and least portable thing you can build on a platform like this. That conversation is in getting your app out.

Putting the shape against the meter

The four shapes and the four meters map onto each other more cleanly than any feature comparison does.

• Internal tool, simple: any of them. Pick on comfort, and let the smallest bill win.
• Internal tool, complex: workload-metered, because nothing else will express the rules.
• Client portal: people-metered, almost without exception.
• Field app, web is fine: depends on write volume. Heavy writing rules out per-row metering quickly.
• Field app, store listing required: published-app metering, because it is the only one that publishes to stores.
• Public product: published-app metering if the logic is simple; workload metering if it is not, with a plan for what success costs.

Notice what is missing from that list: the word "best". None of these shapes has a best platform. Each has a meter that fits and meters that do not.

Two questions that reveal the shape

If you are genuinely unsure which shape you are building, two questions settle it faster than a requirements document.

Who pays you, and do they log in? If the people logging in are the people paying you, you are almost certainly building a portal and you want per-user pricing, because the meter and your revenue move together. If the people logging in cost you money rather than bringing it, you want the meter as far from headcount as possible.

What does a good day look like in your app? If a good day means more records created, you are write-heavy and per-row metering will hurt. If a good day means more people looking at what is already there, per-row metering is your friend and per-user pricing is the risk.

Those two answers, honestly given, narrow four platforms to one more reliably than any feature matrix — and they take two minutes rather than two weeks. The meters themselves are explained in the four meters.